As far as I know (and ignoring my previous efforts on chroniquery along these lines), up until now you had your C/C++ Mozilla backtraces via gdb (chocolate) and your JS backtraces via “call DumpJSStack()” or the debugger keyword from within JS (peanut butter), but these two great flavors had never come together to make a lot of money for dentists.
The screenshots (which is actually just one screenshot split in two) show invocation of a custom python gdb command building on my previous exciting pretty gdb commands. The command has filtered out boring JS interpreter / XPConnect code and interleaved exciting interesting JS stack frames.
The implementation is reasonably simple and intended to be able to be implemented using VProbes to support my recent performance work along those lines. We walk stack frames the usual way. Ahead of time, we have marked out the PC ranges of interesting JS interpreter functions (js_Interpret and js_Execute). If the stack frame’s instruction pointer is in one of those functions we grab the JSContext argument. We pop frames until we reach the native frame those functions allocate from their own stack space (whose boundaries we know from the stack walking).
There is one trick we have to do involving dormantFrameChain. While js_Execute has a consistent and straightforward usage of JS_SaveFrameChain, XPConnect and its quickstub friends are more complex. Right now we use a dumb heuristic that just looks if our frame pointer is 0 and there is a dormantFrameChain, and in that case we restore it. (Thankfully the garbage collector needs to know about the shelved frames, otherwise we might have to chase frames down.) I haven’t put much effort into thinking about it, but the heurstic seems a bit reckless. We could likely just concurrently walk the XPConnect context stack to figure out when to restore dormant frame chains. The existing VProbe JS stack (only) code already goes to the horrible effort to get at the thread-local stack, so it wouldn’t be too much more work. Things probably also fall down during garbage collection right now.
Hg repository is here. Under no circumstances try to use this with jblandy’s excellent archer-mozilla JS magic right now. The current code is very distrustful of gdb.Value in a dumb way and does exceedingly dangerous things wherein pointers are bounced to strings and back to integers because direct integer coercion is forbidden. With pretty printers installed this is likely to break. Also, this is all only tested on 1.9.1.