Closed Bug 836829 Opened 13 years ago Closed 7 years ago

Intermittent test_hanging.html | application timed out after 330 seconds with no output | application crashed [@ libsystem_kernel.dylib + 0x16bf2] [@ libsystem_kernel.dylib + 0x1700e]

Categories

(Core Graveyard :: Plug-ins, defect, P3)

defect

Tracking

(firefox20 affected, firefox21 affected)

RESOLVED WONTFIX
Tracking Status
firefox20 --- affected
firefox21 --- affected

People

(Reporter: RyanVM, Unassigned)

References

Details

(Keywords: crash, intermittent-failure, Whiteboard: [leave open])

Crash Data

https://tbpl.mozilla.org/php/getParsedLog.php?id=19289825&tree=Mozilla-Inbound Rev4 MacOSX Lion 10.7 mozilla-inbound debug test mochitest-3 on 2013-01-30 10:19:22 PST for push 944d04257592 slave: talos-r4-lion-037 422 INFO TEST-START | /tests/dom/plugins/test/test_hanging.html ++DOMWINDOW == 34 (0x10bb642f8) [serial = 73] [outer = 0x1058909c8] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004003: file ../../../../intl/uconv/src/nsCharsetConverterManager.cpp, line 301 ++DOCSHELL 0x10bb65130 == 11 [id = 21] ++DOMWINDOW == 35 (0x10bb65fa8) [serial = 74] [outer = 0x0] WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file ../../../docshell/base/nsDocShell.cpp, line 8335 ++DOMWINDOW == 36 (0x110ccd2b8) [serial = 75] [outer = 0x10bb65fa8] WARNING: NS_ENSURE_TRUE(aURI) failed: file ../../../caps/src/nsScriptSecurityManager.cpp, line 1930 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file ../../../extensions/cookie/nsPermissionManager.cpp, line 944 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file ../../../extensions/permissions/nsContentBlocker.cpp, line 250 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file ../../../extensions/permissions/nsContentBlocker.cpp, line 212 For application/x-test found plugin Test.plugin JavaScript error: chrome://specialpowers/content/SpecialPowersObserverAPI.js, line 183: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref] XPCOM_MEM_BLOAT_LOG: /var/folders/qd/srwd5f710sj0fcl9z464lkj00000gn/T/tmp2AVRwo/runtests_leaks.log Writing to log: /var/folders/qd/srwd5f710sj0fcl9z464lkj00000gn/T/tmp2AVRwo/runtests_leaks_plugin_pid452.log WARNING: Failed to send message!: file ../../../../dom/plugins/ipc/PluginScriptableObjectParent.cpp, line 167 423 INFO TEST-PASS | /tests/dom/plugins/test/test_hanging.html | p.hang() should throw an exception ###!!! [Parent][RPCChannel] Error: Channel timeout: cannot send/recv ###!!! [Parent][RPCChannel] Error: Channel timeout: cannot send/recv WARNING: Failed to send message!: file ../../../../dom/plugins/ipc/PluginScriptableObjectParent.cpp, line 167 424 INFO TEST-PASS | /tests/dom/plugins/test/test_hanging.html | p.setColor should throw after the plugin crashes ###!!! [Parent][AsyncChannel] Error: Channel timeout: cannot send/recv ###!!! [Parent][RPCChannel] Error: Channel timeout: cannot send/recv ###!!! [Parent][RPCChannel] Error: Channel timeout: cannot send/recv TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/test_hanging.html | application timed out after 330 seconds with no output args: ['/usr/sbin/screencapture', '-C', '-x', '-t', 'png', '/var/folders/qd/srwd5f710sj0fcl9z464lkj00000gn/T/mozilla-test-fail_bEejGK'] SCREENSHOT: <see log> Can't trigger Breakpad, just killing process INFO | automation.py | Application ran for: 0:07:08.646965 INFO | automation.py | Reading PID log: /var/folders/qd/srwd5f710sj0fcl9z464lkj00000gn/T/tmpmEWnD3pidlog PROCESS-CRASH | /tests/dom/plugins/test/test_hanging.html | application crashed [@ libsystem_kernel.dylib + 0x16bf2] Crash dump filename: /var/folders/qd/srwd5f710sj0fcl9z464lkj00000gn/T/tmp2AVRwo/minidumps/34868C7C-0776-49CD-B380-523F8D89B379-browser.dmp Operating system: Mac OS X 10.7.2 11C74 CPU: amd64 family 6 model 23 stepping 10 2 CPUs Crash reason: EXC_BREAKPOINT / 0x00000002 Crash address: 0x7fff888b9bf2 Thread 0 (crashed) 0 libsystem_kernel.dylib + 0x16bf2 rbx = 0x00007fff5fbfa2a0 r12 = 0x0000000000000000 r13 = 0x0000000000000203 r14 = 0x0000000000000000 r15 = 0x0000000000000203 rip = 0x00007fff888b9bf2 rsp = 0x00007fff5fbf9f28 rbp = 0x00007fff5fbf9f70 Found by: given as instruction pointer in context 1 libsystem_c.dylib + 0x4d1a0 rip = 0x00007fff9333d1a1 rsp = 0x00007fff5fbf9f30 rbp = 0x00007fff5fbf9f70 Found by: stack scanning 2 XUL!google_breakpad::ExceptionHandler::WriteMinidump(bool) [exception_handler.cc : 290 + 0x7] rip = 0x000000010102d539 rsp = 0x00007fff5fbf9f80 rbp = 0x00007fff5fbfa210 Found by: stack scanning 3 XUL!google_breakpad::ExceptionHandler::WriteMinidump(std::string const&, bool, bool (*)(char const*, char const*, void*, bool), void*) [exception_handler.cc : 305 + 0xb] rbx = 0x00007fff77844860 r12 = 0x00007fff787c7f60 r14 = 0x0000000000000001 r15 = 0x00007fff5fbfa230 rip = 0x000000010102d6ab rsp = 0x00007fff5fbfa220 rbp = 0x00007fff5fbfa320 Found by: call frame info 4 XUL!CrashReporter::CreatePairedMinidumps(unsigned int, unsigned int, nsIFile**) [nsExceptionHandler.cpp:944d04257592 : 2738 + 0x14] rbx = 0x00007fff77844860 r12 = 0x000000000000bf00 r14 = 0x00007fff5fbfa3b8 r15 = 0x000000000000b40b rip = 0x000000010102982d rsp = 0x00007fff5fbfa330 rbp = 0x00007fff5fbfa3a0 Found by: call frame info 5 XUL!bool mozilla::dom::CrashReporterParent::GeneratePairedMinidump<mozilla::plugins::PluginModuleParent>(mozilla::plugins::PluginModuleParent*) [CrashReporterParent.h:944d04257592 : 113 + 0x4] rbx = 0x000000010ce4bed0 r12 = 0x000000010ce4bed0
This is... kinda weird. If the stack is to be believed, then we are in the middle of collecting the paired minidumps for the plugin hanging (which is normal operation): http://hg.mozilla.org/mozilla-central/annotate/cbeab7da0e3a/toolkit/crashreporter/google-breakpad/src/client/mac/handler/exception_handler.cc#l290 I believe that the breakpad thread is thread 2, and this thread should be waking up and creating the minidump of the parent (browser) process: http://hg.mozilla.org/mozilla-central/annotate/cbeab7da0e3a/toolkit/crashreporter/google-breakpad/src/client/mac/handler/exception_handler.cc#l474 It appears to just be waiting for the message which was presumably sent by thread 0. Note that we don't result-check SendMessageToHandlerThread at line 284, though, so it's possible that it's just failing and then we're waiting on a lock which will never be released.
Priority: -- → P3
Any chance the hang UI could kick in and interfere here?
(In reply to Georg Fritzsche [:gfritzsche] from comment #4) > Any chance the hang UI could kick in and interfere here? Sorry, nevermind, that's OS X not Windows.
Windows expresses its regrets that it can't offer anything like the useless stack Mac has.
OS: Mac OS X → All
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > Note that we don't result-check SendMessageToHandlerThread at line 284, > though, so it's possible that it's just failing and then we're waiting on a > lock which will never be released. Filed and patch here: http://code.google.com/p/google-breakpad/issues/detail?id=525
(In reply to Georg Fritzsche [:gfritzsche] from comment #43) > Filed and patch here: > http://code.google.com/p/google-breakpad/issues/detail?id=525 Learning about the breakpad process, this moved to: https://breakpad.appspot.com/554003/
Pushed this upstream, you can land it in m-c if you like: http://code.google.com/p/google-breakpad/source/detail?r=1152
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #46) > Pushed this upstream, you can land it in m-c if you like: > http://code.google.com/p/google-breakpad/source/detail?r=1152 Thanks, pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/e2f4b1c75ff6
Whiteboard: [leave open]
The lack of a stack here is from bug 932349.
Depends on: 1188052
Depends on: 1262336
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.