Closed Bug 529363 Opened 15 years ago Closed 11 years ago

Crash reporter doesn't always show the full stack

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: smaug, Assigned: ted)

References

Details

(Whiteboard: [crashkill][notacrash])

Attachments

(1 file)

breakpad patch
753 bytes, patch
Details | Diff | Splinter Review
http://crash-stats.mozilla.com/report/index/371f77ca-bb89-4337-83f0-ec86e2091115 I don't know if that is a problem with c-s.mozilla.com, or with breakpad or what.
Blocks: 525575
Marking security sensitive, since I may have to attach a minidump here.
jst sent me a minidump via email, I'll take a look.
Assignee: nobody → ted.mielczarek
Here's what I get from running minidump_stackwalk locally (the non-machine-readable output tells us how it found each frame, which is nice): hread 0 (crashed) 0 xul.dll!nsJSContext::InitContext(nsIScriptGlobalObject *) [nsJSEnvironment.c pp:03f9782c86df : 2520 + 0x9] eip = 0x100827a1 esp = 0x0012e5d4 ebp = 0x0012e600 ebx = 0x00000000 esi = 0x01343680 edi = 0x00000000 eax = 0x00000000 ecx = 0x0012e5fc edx = 0x00000000 efl = 0x00010246 Found by: given as instruction pointer in context 1 xul.dll!nsGlobalWindow::SetScriptContext(unsigned int,nsIScriptContext *) [n sGlobalWindow.cpp:03f9782c86df : 1162 + 0x10] eip = 0x10027a1d esp = 0x0012e608 ebp = 0x0012e618 Found by: previous frame's frame pointer 2 xul.dll!nsGlobalWindow::EnsureScriptEnvironment(unsigned int) [nsGlobalWindo w.cpp:03f9782c86df : 1214 + 0xe] eip = 0x1006ff4d esp = 0x0012e620 ebp = 0x01e0c728 Found by: previous frame's frame pointer 3 xul.dll!nsDocShell::EnsureScriptEnvironment() [nsDocShell.cpp:03f9782c86df : 9893 + 0xa] eip = 0x100b8186 esp = 0x0012e650 ebp = 0x0012e704 Found by: call frame info with scanning 4 xul.dll!nsDocShell::GetInterface(nsID const &,void * *) [nsDocShell.cpp:03f9782c86df : 854 + 0x6a] eip = 0x100b8297 esp = 0x0012e67c ebp = 0x0012e6d4 Found by: call frame info with scanning 5 xul.dll!nsGetInterface::operator()(nsID const &,void * *) [nsIInterfaceRequestorUtils.cpp:03f9782c86df : 52 + 0x14] eip = 0x100e03dd esp = 0x0012e6a0 ebp = 0x0012e6d4 Found by: call frame info with scanning 6 xul.dll!nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const &,nsID const &) [nsCOMPtr.cpp:03f9782c86df : 150 + 0x13] eip = 0x101096a7 esp = 0x0012e6c4 ebp = 0x0012e6d4 Found by: call frame info with scanning 7 xul.dll!nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow>(nsCOMPtr_helper const &) [nsCOMPtr.h:03f9782c86df : 621 + 0xb] eip = 0x10008cd0 esp = 0x0012e6d4 ebp = 0x0012e6d4 Found by: call frame info with scanning 8 xul.dll!nsAppShellService::RegisterTopLevelWindow(nsIXULWindow *) [nsAppShellService.cpp:03f9782c86df : 485 + 0x17] eip = 0x10207b52 esp = 0x0012e6dc ebp = 0x0012e6d4 Found by: call frame info
For comparison, here's some of the stack that WinDBG gives: xul!nsJSContext::InitContext xul!nsGlobalWindow::SetScriptContext xul!nsGlobalWindow::EnsureScriptEnvironment xul!nsDocShell::EnsureScriptEnvironment xul!nsDocShell::GetInterface xul!nsGetInterface::operator() xul!nsCOMPtr_base::assign_from_helper xul!nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow> xul!nsAppShellService::RegisterTopLevelWindow xul!nsAppShellService::CreateTopLevelWindow xul!nsAppStartup::CreateChromeWindow2 xul!nsWindowWatcher::OpenWindowJSInternal xul!nsWindowWatcher::OpenWindow xul!NS_InvokeByIndex_P xul!XPCWrappedNative::CallMethod xul!XPC_WN_CallMethod js3250!js_Invoke js3250!js_Interpret js3250!js_Invoke xul!nsXPCWrappedJSClass::CallMethod xul!nsXPCWrappedJS::CallMethod xul!PrepareAndDispatch xul!SharedStub xul!EnumValidate xul!nsCommandLine::EnumerateHandlers mozcrt19!arena_malloc_small mozcrt19!arena_dalloc xul!nsNativeAppSupportWin::HandleCommandLine xul!nsAString_internal::Replace xul!nsNativeAppSupportWin::HandleDDENotification (it keeps going, through user32.dll and then into our event loop)
It looks like the Breakpad stack matches the WinDBG stack up to where it stops, which is good. Just need to figure out why it can't get past frame 8 there.
We should get this fixed by 1.9.3a1, if at all possible.
blocking2.0: --- → ?
Ok, after investigating, it looks like we're missing stack unwind data for frame 8 (nsAppShellService::RegisterTopLevelWindow), so this might be a result of bug 520651. I'll investigate there and see if I can find a root cause.
blocking2.0: ? → ---
Depends on: 520651
Whiteboard: [crashkill] → [crashkill][notacrash]
I have a breakpad patch that might have fixed this. I'd be happy to give it a shot if someone would send me the minidump.
Attached patch breakpad patch — — Splinter Review
I couldn't find anyone on IRC who would send me the minidump, so here's the patch, in the hope that someone else can test it.
Was there some out of band conclusion on cjones' patch, or did this ball get dropped?
I think we probably talked about this on IRC or something, and I wasn't a fan of making Breakpad scan forever for addresses, since that makes it possible to wind up with really incorrect stacks. From my comment 8, it sounds like switching to VC 2010 would solve this for us.
I would still prefer to get wrong-but-filterable frames than miss real ones, but I can't sign up for the work involved in changing the scanner and dump processing etc. A recent example of current fragility in the scanning heuristics was in aborts triggered by abort() instead of raise(SIGABRT) on android(?, I think); breakpad got useful traces out of the latter but fell over on the former. Those kinds of things make me uneasy.
Switching to VS2010 may have fixed this, I'm not sure.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: