I've pushed a repair for the main problem on x86_64 Linux (and other platforms that use DWARF-based stack unwind).
A related symptom I had noticed was that building without gcc optimization used disabled stack traces; that's now fixed. There are still ways to end up with an empty stack trace, but it should happen much less often. At Wed, 07 Aug 2013 17:49:57 -0400, Vincent St-Amour wrote: > > I'm profiling one of the contract benchmarks[1], and I noticed that > sometimes (about 10 out of 300 samples), `continuation-mark-set->context' > would return an empty stack trace. This number is cut down by about half > if I disable the JIT. These samples seem to be spread out throughout > execution (i.e. not all at the beginning or at the end). > > I think this may be a regression. At least I've never observed that > before (and since this causes the contract profiler to error (a bug > which I'll fix), I probably would have noticed). > > This may be a problem because it would reduce the precision of the > profiler by undercounting what actually was on the stack while these > empty samples are taken. > > > To observe this, clone the contract benchmarks repository[1], then run > the attached version of render-guide.rkt inside that directory. To count > the number of empty stack traces, apply the attached patch to the > profiler. > > > Vincent > > > [1] https://github.com/stamourv/contract-benchmarks > > > > ------------------------------------------------------------------------------ > [application/octet-stream "render-guide.rkt"] [~/Desktop & open] [~/Temp & > open] > > ------------------------------------------------------------------------------ > [application/octet-stream > "0001-Have-profiler-print-number-of-empty-stack-traces.patch"] [~/Desktop & > open] [~/Temp & open] > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev