Quick Debugger Tips
December 28th, 2005
In my javascript debugging post I showed a stack trace and mentioned only that it seemed to be running javascript code. Here it is:
0:009> ~0k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f97c 6009db8b js3250!JSLL_MinInt+0x45e2
0012f9c8 6009cdd9 js3250!js_GetSrcNoteOffset+0x5358
0012f9f0 600c7c01 js3250!js_GetSrcNoteOffset+0x45a6
0012fa08 600856b5 js3250!js_GetScriptLineExtent+0x39e6
0012fa28 600b036f js3250!JS_NewStringCopyZ+0x44
0012fa40 600b3e93 js3250!js_FindProperty+0x26c5
This is a good stack to use to point out a few things about debugging without symbols.
If you’re used to stepping through debug code in Visual Studio, your first instict may be to trust the stack printed out here. This would be wrong, for a few reasons.
First, there’s the line telling us: “Stack unwind information not available. Following frames may be wrong.” Stop me if I’ve covered this before, but it probably means that we’re looking at optimized code. Optimized stack frames often have the pointers to each previous stack frame left out (you’ll see this called “frame pointer omission,” or FPO) which makes walking the stack much more difficult for the debugger.
Second, notice the offsets following the function names - most are very high. For example,
js3250!js_GetSrcNoteOffset+0x5358
The +0×5358 indicates that the return address is to a point more than 20KB after the export function given. 20KB is a lot of machine code, so this almost definitely an internal function call and not a return address into the body of js_GetSrcNoteOffset.
I say “almost definitely” instead of “definitely” with good reason. I have personally seen some VB6 functions several thousands of lines long that would certainly generate more than 20KB of machine code. But I guess if you’re dealing with that then you have enough of your own problems without worrying about symbol subtleties in the Windows debuggers.
So the debugger here is showing us the closest symbol to the return address available, which turns out to not be very close at all.
What can we say about this thread’s stack, given just this information? Only that it is very likely to be running javascript code. Not much else.
