Closed Bug 425452 Opened 16 years ago Closed 16 years ago

Crash Reporter gives incomplete stack trace

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 428682

People

(Reporter: johnjbarton, Unassigned)

References

Details

Look at the crashing thread for 
http://crash-stats.mozilla.com/report/index/8d767985-fc12-11dc-aff7-001a4bd43e5c
0  	@0x7ff00030  	
1 	js_Invoke 	mozilla/js/src/jsinterp.c:1303
2 	fun_apply 	mozilla/js/src/jsfun.c:1650
3 	js_Interpret 	mozilla/js/src/jsinterp.c:4824
4 	js_Invoke 	mozilla/js/src/jsinterp.c:1303
5 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1475
6 	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559
7 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
8 	SharedStub 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
9 	jsds_ExecutionHookProc 	mozilla/js/jsd/jsd_xpc.cpp:690

The ninth and last entry cannot be the end of the thread, its the middle of some long stack and we need the rest of of it. I can't figure out which javascript method is being called, but I might get some hints if the rest of the stack where there.
Blocks: 422767
No longer blocks: 422676
w/o a proper frame 0 you can't assume valid frames past that.

Module|user32.dll|5.1.2600.3099|user32.pdb|92D15332471547DCA0D75061B8B6CDA42|0x7e410000|0x7e49ffff|0
is the highest library i can find. you basically jumped into garbage, and all bets are off.

try windbg, and see if !analyze -v is friendlier.
Sorry I was not clear: its bottom of the stack that is missing. I realize that js_Invoke went off, but to create a testcase I need frames 10, 11, ...

John
you weren't unclear. you're just assuming it's crashreporter's fault. i'm saying that w/o symbols for frame 0, all frames past that are at best best guesses and can easily be totally wrong.
For Crowder: this crash occurs with Firebug 1.2 tip and Chromebug tip whenever I click on an Input element in a google code page.  I am hoping getfirebug.com will have versions of these extensions soon in case I cannot make a testcase. 
Yeah, if the stack has been corrupted (as looks likely, since it appears that it's calling a stack address here), then I don't think there's anything that breakpad can do to recover that information.  I can't figure out what component this bug should really be in, so cc:ing some breakpad expertise in lieu.
Product: Firefox → Core
QA Contact: general → general
If you can reproduce this easily, you can test this theory by using the symbol server and asking WinDBG for a stack trace. If WinDBG can get you a better stack, then you can save the dump file and we can file a bug on Breakpad to improve the stack walking. If WinDBG gets equally confused, then it's just a crummy stack, and there isn't anything we can do about it.

I can reproduce, and windbg gives this:

ChildEBP RetAddr  
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012d0a8 6015de56 0x0
0012d1ec 60110069 js3250!js_Interpret+0x42db6
0012d2a0 6056d515 js3250!js_Invoke(struct JSContext * cx = 0x0255d3a0, unsigned int argc = 2, long * vp = 0x02a45824, unsigned int flags = 2)+0x3b9 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\jsinterp.c @ 1304]
0012d42c 605a17d8 xul!nsXPCWrappedJSClass::CallMethod(class nsXPCWrappedJS * wrapper = 0x0282eb80, unsigned short methodIndex = 9, struct XPTMethodDescriptor * info = 0x020086c0, struct nsXPTCMiniVariant * nativeParams = 0x0012d468)+0x635 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp @ 1476]
0012d444 6064303e xul!nsXPCWrappedJS::CallMethod(unsigned short methodIndex = 0x30b0, struct XPTMethodDescriptor * info = 0x00000009, struct nsXPTCMiniVariant * params = 0x0012d520)+0x38 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp @ 560]
0012d4f8 606430a5 xul!PrepareAndDispatch(class nsXPTCStubBase * self = 0x028330b0, unsigned int methodIndex = 9, unsigned int * args = 0x0012d520, unsigned int * stackBytesToPop = 0x0012d510)+0xe7 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 114]
0012d514 60642f53 xul!SharedStub(void)+0x16 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp @ 142]
0012d538 605584e2 xul!NS_InvokeByIndex_P(class nsISupports * that = 0x028330b0, unsigned int methodIndex = 0x21767c0, unsigned int paramCount = 0x31741c0, struct nsXPTCVariant * params = 0x0012d608)+0x27 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp @ 102]
0012d5d0 604d19c4 xul!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x00000000, XPCWrappedNative::CallMode mode = 42152112 (No matching enumerant))+0x542 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 2371]
00000000 00000000 xul!nsScriptSecurityManager::GetCxSubjectPrincipal(struct JSContext * cx = <Memory access error>)+0x1c [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\caps\src\nsscriptsecuritymanager.cpp @ 434]

That does look better. If you can get a minidump file + the associated symbols for that build, we could file a bug on Breakpad.

.dump /maipwd /u /ba /c "comment" file

however, i highly doubt that the crash you're reporting is equivalent to one that breakpad rendered w/ an unhappy stack.

00000000 00000000 xul!nsScriptSecurityManager::GetCxSubjectPrincipal
^        ^        this is kinda odd.

among the basic problems, you don't have jsd_ in your stack.
> however, i highly doubt that the crash you're reporting is equivalent to one
> that breakpad rendered w/ an unhappy stack.
> 
> 00000000 00000000 xul!nsScriptSecurityManager::GetCxSubjectPrincipal
> ^        ^        this is kinda odd.
> 
> among the basic problems, you don't have jsd_ in your stack.

You might be right.  I assumed this overlapped with 425499, as per John's comment (see c11).  My stacks are all partial too, whether it's the same or not.  Is it still worth me doing a minidump?

Dave


i still want to see the .dmp :)
Here you go.  If I've done this incorrectly, or you need more, let me know.

http://cs.senecac.on.ca/~david.humphrey/tmp/425452.cab
i claim breakpad wouldn't do any better w/ your stack than it did w/ this other stack.

0012d1ec 60110069 js3250!js_Interpret+0x42db6
afaict, this is beyond the reasonable bounds of that function (there's certainly no line number information near there)

      601202ef cc              int     3
js3250!js_GetClassId:
 2408 601202f0 0fb64107        movzx   eax,byte ptr [ecx+7]

601202f0 -js3250!js_Interpret =00005250

your 6015de56 which is the return address from 0x0 is well beyond 601202ef which is the beginning of the function after 
      6011b09f cc              int     3
js3250!js_Interpret:
 2439 6011b0a0 55              push    ebp

so, while it's probably in the same class of unhappy stacks, I don't think it helps breakpad. it might help someone w/ lots of time figure out what's actually going south (maybe).

I think that if this is easy enough for you to trigger the thing to do is probably to start by adding some logging breakpoints. here's an example:

bp js3250!JS_BeginRequest "kp; g"

the g means "go"(i.e. continue), the "kp" is one of many ways to get stack traces. You're free to pick whichever k variant you like. And you'll definitely need to pick which functions (or addresses/offsets) you want to breakpoint.

The obvious candidates are js_Interpret+js_Invoke+jsds_*HookProc. But once you get a feel for that you should be able to do something like breakpointing all call/jump frames in js_Invoke/js_Interpret. And if you get really clever you can use dt, dv, r to show other things which would let you see more bits before the world goes bad.

"k 10; dv; r; g" is a possibility

I'd like to not walk you through the whole process (experiment, it's fun), but if you really need more hints, you should be able to find someone who can help you find me on IRC.

anyway, offhand I'd say this bug isn't valid :). crash reporter seems to do as good of a job as it can do. (That said, since this bug has nothing else to do, I really don't mind using it for analyzing the stacks we do have.)
I stopped seeing this one and I cannot reproduce it in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032805 Minefield/3.0pre
Should this be marked as WFM?

Related to bug 428682?
Yeah, it's possible that it was related, I'd have to look at when that original processor change was pushed to be sure.

(In reply to comment #15)
> Should this be marked as WFM?
> 
> Related to bug 428682?
> 

I think so (and I'm marking it as such). Notice that comment #0 lists only 10 frames and that bug 428682 was about Soccorro erroneously stopping after recording only the top 10 frames in the stack.

I was seeing the same thing on Sm-trunk/Linux crashes, but my latest crash is from 2008-04-15 and the fix for bug 428682 landed on 2008-04-18.

If you want to REOPEN, please explain clearly why this isn't a dupe.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.