Closed Bug 505016 Opened 16 years ago Closed 11 years ago

crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] or [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]

Categories

(Core :: XPCOM, defect)

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

Tracking

()

Status:
VERIFIED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -
status1.9.1 --- wanted

People

(Reporter: wsmwk, Assigned: mrbkap)

Details

(Keywords: crash, Whiteboard: [tbird crash])

Crash Data

crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] seen more with FF - http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsXPCWrappedJS%3A%3AQueryInterface%28nsID%20const%26%2C%20void**%29&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsXPCWrappedJS%3A%3AQueryInterface%28nsID%20const%26%2C%20void**%29 but there is also this Thunderbird crash... bp-b2cb2e83-f2c3-4d6d-ad87-9f4822090527 nsXPCWrappedJS::QueryInterface js/src/xpconnect/src/xpcwrappedjs.cpp:173 canonicalize xpcom/base/nsCycleCollector.cpp:1108 GCGraphBuilder::NoteXPCOMRoot xpcom/base/nsCycleCollector.cpp:1330 XPCJSRuntime::AddXPConnectRoots js/src/xpconnect/src/xpcjsruntime.cpp:437 nsXPConnect::BeginCycleCollection js/src/xpconnect/src/nsXPConnect.cpp:573 nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2323 nsCycleCollector_beginCollection xpcom/base/nsCycleCollector.cpp:2916 XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:391 js_GC js/src/jsgc.cpp:3506 JS_GC js/src/jsapi.cpp:2487 nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:478 nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2256 nsCycleCollector_collect xpcom/base/nsCycleCollector.cpp:2904 nsJSContext::CC dom/src/base/nsJSEnvironment.cpp:3419 nsJSContext::MaybeCC dom/src/base/nsJSEnvironment.cpp:3471 nsJSContext::CCIfUserInactive dom/src/base/nsJSEnvironment.cpp:3488 DocumentViewerImpl::LoadComplete layout/base/nsDocumentViewer.cpp:1037 nsDocShell::EndPageLoad docshell/base/nsDocShell.cpp:5243 nsWebShell::EndPageLoad docshell/base/nsWebShell.cpp:1015 nsDocShell::OnStateChange docshell/base/nsDocShell.cpp:5139 nsDocLoader::FireOnStateChange uriloader/base/nsDocLoader.cpp:1235 nsDocLoader::doStopDocumentLoad uriloader/base/nsDocLoader.cpp:858 nsDocLoader::DocLoaderIsEmpty uriloader/base/nsDocLoader.cpp:763 nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:679 nsLoadGroup::RemoveRequest netwerk/base/src/nsLoadGroup.cpp:688 nsDocument::DoUnblockOnload content/base/src/nsDocument.cpp:7026 nsBindingManager::DoProcessAttachedQueue content/xbl/src/nsBindingManager.cpp:978 nsRunnableMethod<nsBindingManager>::Run nsThreadUtils.h:264 nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:121 nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:374 CFRunLoopRunSpecific CFRunLoopRunInMode RunCurrentEventLoopInMode ReceiveNextEventCommon BlockUntilNextEventMatchingListInMode _DPSNextEvent -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] -[NSApplication run] nsAppShell::Run widget/src/cocoa/nsAppShell.mm:693 nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:192 XRE_main toolkit/xre/nsAppRunner.cpp:3279 main nsMailApp.cpp:103
not much concern here for thunderbird ... only ~6 crashes in 6 months example bp-c31ba322-2a67-4cb2-b58d-1c1d92090327 Module Signature [Expand] Source 0 thunderbird-bin nsXPCWrappedJS::QueryInterface js/src/xpconnect/src/xpcwrappedjs.cpp:173 1 libxpcom_core.dylib canonicalize xpcom/base/nsCycleCollector.cpp:1108 2 libxpcom_core.dylib GCGraphBuilder::NoteXPCOMRoot xpcom/base/nsCycleCollector.cpp:1330 3 thunderbird-bin XPCJSRuntime::AddXPConnectRoots js/src/xpconnect/src/xpcjsruntime.cpp:437 4 thunderbird-bin nsXPConnect::BeginCycleCollection js/src/xpconnect/src/nsXPConnect.cpp:573 5 libxpcom_core.dylib nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2323 6 libxpcom_core.dylib nsCycleCollector_beginCollection xpcom/base/nsCycleCollector.cpp:2916 7 thunderbird-bin XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:391 8 libmozjs.dylib js_GC js/src/jsgc.cpp:3506 9 libmozjs.dylib JS_GC js/src/jsapi.cpp:2487 10 thunderbird-bin nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:478 11 libxpcom_core.dylib nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2256 12 libxpcom_core.dylib nsCycleCollector_collect xpcom/base/nsCycleCollector.cpp:2904 13 thunderbird-bin nsJSContext::CC dom/src/base/nsJSEnvironment.cpp:3419 14 thunderbird-bin nsJSContext::MaybeCC dom/src/base/nsJSEnvironment.cpp:3471 15 thunderbird-bin nsXMLHttpRequest::RequestCompleted content/base/src/nsXMLHttpRequest.cpp:2407 16 thunderbird-bin nsXMLHttpRequest::OnStopRequest content/base/src/nsXMLHttpRequest.cpp:2343 17 thunderbird-bin nsHttpChannel::OnStopRequest netwerk/protocol/http/src/nsHttpChannel.cpp:4851 18 thunderbird-bin nsInputStreamPump::OnStateStop netwerk/base/src/nsInputStreamPump.cpp:576 19 thunderbird-bin nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:401 20 libxpcom_core.dylib nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:111 21 libxpcom_core.dylib nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 22 libxpcom_core.dylib NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 23 thunderbird-bin nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:121 24 thunderbird-bin nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:374 25 CoreFoundation CoreFoundation@0x735f4 26 CoreFoundation CoreFoundation@0x73cd7 27 HIToolbox HIToolbox@0x302bf 28 HIToolbox HIToolbox@0x30011 29 HIToolbox HIToolbox@0x2ff4c 30 AppKit AppKit@0x40d7c 31 AppKit AppKit@0x4062f 32 thunderbird-bin nsAppShell::ProcessNextNativeEvent widget/src/cocoa/nsAppShell.mm:626 33 thunderbird-bin nsBaseAppShell::DoProcessNextNativeEvent widget/src/xpwidgets/nsBaseAppShell.cpp:151 34 thunderbird-bin nsBaseAppShell::OnProcessNextEvent widget/src/xpwidgets/nsBaseAppShell.cpp:278 35 thunderbird-bin nsAppShell::OnProcessNextEvent widget/src/cocoa/nsAppShell.mm:766 36 libxpcom_core.dylib nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:497 37 libxpcom_core.dylib NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 38 thunderbird-bin nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:121 39 thunderbird-bin nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:374 40 CoreFoundation CoreFoundation@0x735f4 41 CoreFoundation CoreFoundation@0x73cd7 42 HIToolbox HIToolbox@0x302bf 43 HIToolbox HIToolbox@0x300d8 44 HIToolbox HIToolbox@0x2ff4c 45 AppKit AppKit@0x40d7c 46 AppKit AppKit@0x4062f 47 AppKit AppKit@0x3966a 48 thunderbird-bin nsAppShell::Run widget/src/cocoa/nsAppShell.mm:693 49 thunderbird-bin nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:192 50 thunderbird-bin XRE_main toolkit/xre/nsAppRunner.cpp:3279 51 thunderbird-bin main nsMailApp.cpp:103
For Thunderbird, changes to socorro processing have morphed crashes to _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**) ~5% of Thunderbird 3.0 crashes, making this #5 crasher (when excluding #1 enigmail) FF signature is unchanged
Keywords: topcrash
Summary: crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] → crash [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] or [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
Keywords: qawanted
gc issue? or is upper stack totally bogus and the problem really in thunderbird code? for example bp-0f09a857-dbc9-4565-bab3-7bca52100104 (has no extensions) 0 ntdll.dll KiFastSystemCallRet 1 ntdll.dll NtWaitForSingleObject 2 kernel32.dll WaitForSingleObjectEx 3 kernel32.dll WaitForSingleObject 4 thunderbird.exe google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:562 5 thunderbird.exe google_breakpad::ExceptionHandler::HandlePureVirtualCall toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:506 6 mozcrt19.dll _purecall objdir-tb/mozilla/memory/jemalloc/src/purevirt.c:47 7 thunderbird.exe nsXPCWrappedJS::QueryInterface js/src/xpconnect/src/xpcwrappedjs.cpp:173 8 xpcom_core.dll canonicalize xpcom/base/nsCycleCollector.cpp:1161 9 xpcom_core.dll GCGraphBuilder::NoteXPCOMChild xpcom/base/nsCycleCollector.cpp:1447 10 thunderbird.exe nsXPCWrappedJS::cycleCollection::Traverse js/src/xpconnect/src/xpcwrappedjs.cpp:74 11 xpcom_core.dll GCGraphBuilder::Traverse xpcom/base/nsCycleCollector.cpp:1372 12 xpcom_core.dll nsCycleCollector::MarkRoots xpcom/base/nsCycleCollector.cpp:1571 13 xpcom_core.dll nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2504 14 thunderbird.exe XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:390 15 js3250.dll js_GC js/src/jsgc.cpp:3500 16 js3250.dll JS_GC js/src/jsapi.cpp:2458 17 thunderbird.exe nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:477 18 xpcom_core.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2386 19 xpcom_core.dll nsCycleCollector_collect xpcom/base/nsCycleCollector.cpp:3045 20 thunderbird.exe nsJSContext::CC dom/src/base/nsJSEnvironment.cpp:3512 21 thunderbird.exe nsJSContext::MaybeCC dom/src/base/nsJSEnvironment.cpp:3580 22 thunderbird.exe nsJSContext::CCIfUserInactive dom/src/base/nsJSEnvironment.cpp:3597 23 thunderbird.exe GCTimerFired dom/src/base/nsJSEnvironment.cpp:3620 24 xpcom_core.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:420 25 xpcom_core.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:512 26 xpcom_core.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:521 27 xpcom_core.dll NS_ProcessNextEvent_P objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:236 28 thunderbird.exe nsXULWindow::ShowModal xpfe/appshell/src/nsXULWindow.cpp:415 29 thunderbird.exe nsContentTreeOwner::ShowAsModal xpfe/appshell/src/nsContentTreeOwner.cpp:528
blocking1.9.1: --- → ?
wayne: this basically means that an object was in a certain state of dead and its pointers were swapped for _purecall, that object should have been unreachable (since it obviously died...), however it obviously wasn't properly unreachable because the cyclecollector hit it. The stack is valid. The reason you see frames 0..5 is because of how _purecall works, in general a crash is an access violation, but for _purecalls, you don't quite crash, you're dead in a way that would normally mean calling into really random confusing bad states, _purecall helps out developers by explaining "you're here because of purecall", and classically it does this by tossing up a genuine dialog saying "whoops, someone made a purecall", since that dialog isn't quite the same thing as actually crashing (when you dismiss the dialog, the app kills itself), breakpad needs to have its own special code specifically for it, which is the explanation for how frames 6..4 are shaped. The actual thread responsible for doing the dump is another one, and in order to let the stack dumping work, the crashed thread has to block waiting (which explains frames 3..0).
Assignee: nobody → mrbkap
blocking1.9.1: ? → ---
blocking2.0: --- → ?
status1.9.1: --- → wanted
mrbkap, any theories on when you might be able to look at this?
So, this is going to be extremely hard to chase down. I don't know when I'm going to get a chance to really look at this. Sorry.
still steady at #5 crash for v3.0.4 not many crash comments, but all are about adding new accounts. Tried to open new account. tried to add an account checked with errors smtp and pop settings then after correcting it was impossible to re-check config so i canceled, then re-create account on check of config this time crash Repeatable crash after installing and filling out the first email account. Cycles through detection of pop3 and smtp server information and then dies. Windows 7. so pmed bp-cb61a41a-9b59-4605-bdfb-c7aa82100412 (joel)
Whiteboard: js_LookupPropertyWithFlags
Whiteboard: js_LookupPropertyWithFlags → [tbird crash]
I've just posted on the extension development forum because I hit the same crash with my add-on. I'm not sure how related the issues are but there appears to be a common use of nsIOutputStreamCallback.onOutputStreamReady(). Even if it turns out that I'm just doing something stupid in my extension, I thought it might help narrow down what's causing these crashes. http://forums.mozillazine.org/viewtopic.php?f=19&t=1907489
blocking 1.9.3 final+
blocking2.0: ? → final+
looks like this has reduced in volume (at least for firefox). has it done the same for tbird? date tl crashes at, count build, count build, ... nsXPCWrappedJS::QueryInterface.nsID.const...void... 20101001 14 10 3.6.102010091412, 1 4.0b52010083108, 1 3.6.82010072215, 1 3.6.32010040108, 1 3.0.192010031422, 20101002 10 8 3.6.102010091412, 1 4.0b32010080519, 1 3.6b22009110818, 20101003 12 10 3.6.102010091412, 1 4.0b12010063014, 1 3.6.82010072215, 20101004 8 4 3.6.102010091412, 1 4.0b62010091408, 1 3.6b42009112421, 1 3.6.82010072215, 1 3.5.132010091413, 20101005 9 6 3.6.102010091412, 1 3.6.32010040108, 1 3.6.112010100108, 1 3.5.132010091413, 20101006 7 6 3.6.102010091412, 1 3.5.132010091413, 20101007 7 4 3.6.102010091412, 1 3.6.82010072215, 1 3.6.32010040108, 1 3.0.32008092417, 20101008 7 5 3.6.102010091412, 1 3.7a32010031509, 1 3.5.132010091413, 20101009 8 5 3.6.102010091412, 1 4.0b62010091408, 1 3.6.112010100108, 1 3.5b42009042320, 20101010 5 3 3.6.102010091412, 1 4.0b52010083108, 1 3.6.82010072215,
Keywords: topcrash
chris, For tbird... nsXPCWrappedJS::QueryInterface(nsID const&, void**) never existed in great quantity in thunderbird - roughly less than 1-2 crashes per month per version. So there's no way to assign numerical significance to any changes in crash rate up or down in the past 6 months. _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**) is a different beast - non-existent in v3.1.anything**. but big numbers (2,000+ plus crashes per month per the most current v3.0 release of the month) until we turned on the MU major update to v3.1. **however, there are rare crashes on trunk such as bp-b1a438c4-1d5b-424f-8c79-9b9432100919 bp-2654295c-6ec4-4b41-9bbd-e53012100921 bp-5fc1c019-3895-4b62-bca6-a64122100916
firefox 4.0 b5/6 volume regress part of this bug has been spun off to bug 607867
I see 0 crashes with the signature "nsXPCWrappedJS::QueryInterface(nsID const&, void**)" since 11/4, so not blocking on this. Bug 607867 seems to cover the other signature, so I'm doubtful there's even a reason to keep this bug open any more...
blocking2.0: final+ → -
jst, thanks for checking and updating this. I agree this can be closed thunderbird _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**) no crashes in 3.1, and no trunk crashes since build 20100915033551 bp-2654295c-6ec4-4b41-9bbd-e53012100921 ... so this is "gone" thunderbird nsXPCWrappedJS::QueryInterface(nsID const&, void**) bp-d8ef4e06-1f90-496d-9c40-a559e2101206 v3.1.6 EXCEPTION_ACCESS_VIOLATION_READ 0x1 bp-b1c7d3fe-3d62-4d4d-bec8-13ea02101202 v3.1.6 EXCEPTION_ACCESS_VIOLATION_READ 0x40 bp-0840ec4f-6617-4078-8300-94b302101118 v3.1.6 SIGSEGV 0x4 ... is all I find in the last month, all different stacks and none match this bug still a topcrash for v3.0.x. but for 3.1.x and trunk this is gone => WFM
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
This crash is happening in 4.0 and 4.0.1, reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Crash Signature: [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
I don't see any crashes like this in the top 300 on Firefox 31 beta.
Status: REOPENED → RESOLVED
Crash Signature: [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)] → [@ nsXPCWrappedJS::QueryInterface(nsID const&, void**)] [@ _purecall | nsXPCWrappedJS::QueryInterface(nsID const&, void**)]
Closed: 14 years ago → 11 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.