https://treeherder.mozilla.org/logviewer.html#?job_id=33784063&repo=mozilla-inbound 06:40:51 INFO - PROCESS-CRASH | /html/syntax/parsing/html5lib_adoption01.html?run_type=write | application crashed [@ JSAutoCompartment::JSAutoCompartment] 06:40:51 INFO - Crash dump filename: /tmp/tmpDH5F6W.mozrunner/minidumps/522dcd9a-41d7-a228-6335e38e-415da535.dmp 06:40:51 INFO - Operating system: Linux 06:40:51 INFO - 0.0.0 Linux 3.2.0-76-generic-pae #111-Ubuntu SMP Tue Jan 13 22:34:29 UTC 2015 i686 06:40:51 INFO - CPU: x86 06:40:51 INFO - GenuineIntel family 6 model 62 stepping 4 06:40:51 INFO - 1 CPU 06:40:51 INFO - 06:40:51 INFO - Crash reason: SIGSEGV 06:40:51 INFO - Crash address: 0xff00fa8 06:40:51 INFO - Process uptime: not available 06:40:51 INFO - 06:40:51 INFO - Thread 0 (crashed) 06:40:51 INFO - 0 libxul.so!JSAutoCompartment::JSAutoCompartment [jsobj.h:00f781f21da3 : 170 + 0x0] 06:40:51 INFO - eip = 0xb40f5780 esp = 0xbfe09cf0 ebp = 0xbfe09d18 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaa526000 edi = 0xbfe09d68 eax = 0x0ff00fa0 ecx = 0x00013a1b 06:40:51 INFO - edx = 0xaa526000 efl = 0x00210246 06:40:51 INFO - Found by: given as instruction pointer in context 06:40:51 INFO - 1 libxul.so!JS_CopyPropertiesFrom [jsobj.cpp:00f781f21da3 : 1089 + 0x18] 06:40:51 INFO - eip = 0xb419fd8b esp = 0xbfe09d20 ebp = 0xbfe09dc8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaa526000 edi = 0xbfe09d68 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 2 libxul.so!mozilla::dom::ReparentWrapper [BindingUtils.cpp:00f781f21da3 : 2110 + 0x9] 06:40:51 INFO - eip = 0xb26b42ea esp = 0xbfe09dd0 ebp = 0xbfe09e88 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe09e60 edi = 0xbfe09df4 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 3 libxul.so!nsHTMLDocument::Open [nsHTMLDocument.cpp:00f781f21da3 : 1641 + 0xb] 06:40:51 INFO - eip = 0xb2900ad8 esp = 0xbfe09e90 ebp = 0xbfe0a148 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a048 edi = 0x94613800 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 4 libxul.so!mozilla::dom::HTMLDocumentBinding::open [HTMLDocumentBinding.cpp:00f781f21da3 : 526 + 0x29] 06:40:51 INFO - eip = 0xb262b4dc esp = 0xbfe0a150 ebp = 0xbfe0a378 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a1b8 edi = 0xbfe0a3b4 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 5 libxul.so!mozilla::dom::GenericBindingMethod [BindingUtils.cpp:00f781f21da3 : 2812 + 0x6] 06:40:51 INFO - eip = 0xb26b30c4 esp = 0xbfe0a380 ebp = 0xbfe0a3e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xb5ee07d0 edi = 0xbfe0a3c0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 6 libxul.so!js::CallJSNative [jscntxtinlines.h:00f781f21da3 : 235 + 0x11] 06:40:51 INFO - eip = 0xb42c7611 esp = 0xbfe0a3f0 ebp = 0xbfe0a438 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a588 edi = 0xbfe0a598 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 7 libxul.so!js::InternalCallOrConstruct [Interpreter.cpp:00f781f21da3 : 453 + 0x13] 06:40:51 INFO - eip = 0xb430ccb0 esp = 0xbfe0a440 ebp = 0xbfe0a4a8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a558 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 8 libxul.so!InternalCall [Interpreter.cpp:00f781f21da3 : 498 + 0x15] 06:40:51 INFO - eip = 0xb430d0f4 esp = 0xbfe0a4b0 ebp = 0xbfe0a4e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x8f7c9400 edi = 0xffffff8c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 9 libxul.so!js::Call [Interpreter.cpp:00f781f21da3 : 517 + 0x8] 06:40:51 INFO - eip = 0xb430d214 esp = 0xbfe0a4f0 ebp = 0xbfe0a4f8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a558 edi = 0xbfe0a598 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 10 libxul.so!js::Wrapper::call [Wrapper.cpp:00f781f21da3 : 165 + 0x21] 06:40:51 INFO - eip = 0xb424bf0e esp = 0xbfe0a500 ebp = 0xbfe0a5e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x00000002 edi = 0xbfe0a598 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 11 libxul.so!js::CrossCompartmentWrapper::call [CrossCompartmentWrapper.cpp:00f781f21da3 : 329 + 0x1d] 06:40:51 INFO - eip = 0xb420d9b5 esp = 0xbfe0a5f0 ebp = 0xbfe0a638 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a624 edi = 0xbfe0a6d0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 12 libxul.so!js::Proxy::call [Proxy.cpp:00f781f21da3 : 401 + 0x1a] 06:40:51 INFO - eip = 0xb420027a esp = 0xbfe0a640 ebp = 0xbfe0a6a8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaa526000 edi = 0xbfe0a664 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 13 libxul.so!js::proxy_Call [Proxy.cpp:00f781f21da3 : 690 + 0x16] 06:40:51 INFO - eip = 0xb4201107 esp = 0xbfe0a6b0 ebp = 0xbfe0a6e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0a6c4 edi = 0xa5ea91c0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 14 libxul.so!js::CallJSNative [jscntxtinlines.h:00f781f21da3 : 235 + 0x11] 06:40:51 INFO - eip = 0xb42c7611 esp = 0xbfe0a6f0 ebp = 0xbfe0a738 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa5ea91b0 edi = 0xa5ea91c0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 15 libxul.so!js::InternalCallOrConstruct [Interpreter.cpp:00f781f21da3 : 441 + 0x10] 06:40:51 INFO - eip = 0xb430cfd2 esp = 0xbfe0a740 ebp = 0xbfe0a7a8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0aa28 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 16 libxul.so!InternalCall [Interpreter.cpp:00f781f21da3 : 498 + 0x15] 06:40:51 INFO - eip = 0xb430d0f4 esp = 0xbfe0a7b0 ebp = 0xbfe0a7e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x8f7c93d0 edi = 0xffffff8c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 17 libxul.so!Interpret [Interpreter.cpp:00f781f21da3 : 504 + 0xd] 06:40:51 INFO - eip = 0xb4301c37 esp = 0xbfe0a7f0 ebp = 0xbfe0aaf8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0aa28 edi = 0x00000000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 18 libxul.so!js::RunScript [Interpreter.cpp:00f781f21da3 : 399 + 0x9] 06:40:51 INFO - eip = 0xb430caf7 esp = 0xbfe0ab00 ebp = 0xbfe0ab98 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0abd0 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 19 libxul.so!js::InternalCallOrConstruct [Interpreter.cpp:00f781f21da3 : 471 + 0xf] 06:40:51 INFO - eip = 0xb430ce02 esp = 0xbfe0aba0 ebp = 0xbfe0ac08 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0acb0 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 20 libxul.so!InternalCall [Interpreter.cpp:00f781f21da3 : 498 + 0x15] 06:40:51 INFO - eip = 0xb430d0f4 esp = 0xbfe0ac10 ebp = 0xbfe0ac48 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x967bda60 edi = 0xffffff8c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 21 libxul.so!js::Call [Interpreter.cpp:00f781f21da3 : 517 + 0x8] 06:40:51 INFO - eip = 0xb430d214 esp = 0xbfe0ac50 ebp = 0xbfe0ac58 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0acb0 edi = 0xbfe0acb0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 22 libxul.so!js::fun_apply [jsfun.cpp:00f781f21da3 : 1320 + 0x21] 06:40:51 INFO - eip = 0xb416a757 esp = 0xbfe0ac60 ebp = 0xbfe0af28 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0ac9c edi = 0xbfe0acb0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 23 libxul.so!js::CallJSNative [jscntxtinlines.h:00f781f21da3 : 235 + 0x11] 06:40:51 INFO - eip = 0xb42c7611 esp = 0xbfe0af30 ebp = 0xbfe0af78 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0b270 edi = 0xbfe0b280 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 24 libxul.so!js::InternalCallOrConstruct [Interpreter.cpp:00f781f21da3 : 453 + 0x13] 06:40:51 INFO - eip = 0xb430ccb0 esp = 0xbfe0af80 ebp = 0xbfe0afe8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0b174 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 25 libxul.so!InternalCall [Interpreter.cpp:00f781f21da3 : 498 + 0x15] 06:40:51 INFO - eip = 0xb430d0f4 esp = 0xbfe0aff0 ebp = 0xbfe0b028 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa61022b8 edi = 0xffffff8c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 26 libxul.so!js::jit::DoCallFallback [BaselineIC.cpp:00f781f21da3 : 5981 + 0x15] 06:40:51 INFO - eip = 0xb468baad esp = 0xbfe0b030 ebp = 0xbfe0b218 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa446a175 edi = 0x00000002 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 27 0xaf82167c 06:40:51 INFO - eip = 0xaf82167c esp = 0xbfe0b220 ebp = 0xbfe0b290 ebx = 0xbfe0b248 06:40:51 INFO - esi = 0xa46163eb edi = 0xa33616e8 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 28 0xa33616e8 06:40:51 INFO - eip = 0xa33616e8 esp = 0xbfe0b298 ebp = 0xbfe0b30c 06:40:51 INFO - Found by: previous frame's frame pointer 06:40:51 INFO - 29 0xaf820c4a 06:40:51 INFO - eip = 0xaf820c4a esp = 0xbfe0b314 ebp = 0xbfe0b348 06:40:51 INFO - Found by: previous frame's frame pointer 06:40:51 INFO - 30 libxul.so!EnterBaseline [BaselineJIT.cpp:00f781f21da3 : 156 + 0x34] 06:40:51 INFO - eip = 0xb3dfb112 esp = 0xbfe0b350 ebp = 0xbfe0b4f8 06:40:51 INFO - Found by: previous frame's frame pointer 06:40:51 INFO - 31 libxul.so!js::jit::EnterBaselineMethod [BaselineJIT.cpp:00f781f21da3 : 194 + 0x7] 06:40:51 INFO - eip = 0xb3e02f4f esp = 0xbfe0b500 ebp = 0xbfe0b5c8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaa526000 edi = 0xbfe0b58c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 32 libxul.so!Interpret [Interpreter.cpp:00f781f21da3 : 2926 + 0x12] 06:40:51 INFO - eip = 0xb430a414 esp = 0xbfe0b5d0 ebp = 0xbfe0b8d8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0b808 edi = 0xbfe0b83c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 33 libxul.so!js::RunScript [Interpreter.cpp:00f781f21da3 : 399 + 0x9] 06:40:51 INFO - eip = 0xb430caf7 esp = 0xbfe0b8e0 ebp = 0xbfe0b978 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0b9b0 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 34 libxul.so!js::InternalCallOrConstruct [Interpreter.cpp:00f781f21da3 : 471 + 0xf] 06:40:51 INFO - eip = 0xb430ce02 esp = 0xbfe0b980 ebp = 0xbfe0b9e8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0ba78 edi = 0xaa526000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 35 libxul.so!InternalCall [Interpreter.cpp:00f781f21da3 : 498 + 0x15] 06:40:51 INFO - eip = 0xb430d0f4 esp = 0xbfe0b9f0 ebp = 0xbfe0ba28 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x8f7c9060 edi = 0xffffff8c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 36 libxul.so!js::Call [Interpreter.cpp:00f781f21da3 : 517 + 0x8] 06:40:51 INFO - eip = 0xb430d214 esp = 0xbfe0ba30 ebp = 0xbfe0ba38 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0ba78 edi = 0xbfe0ba78 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 37 libxul.so!JS::Call [jsapi.cpp:00f781f21da3 : 2840 + 0x24] 06:40:51 INFO - eip = 0xb411f077 esp = 0xbfe0ba40 ebp = 0xbfe0baf8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0bb68 edi = 0xbfe0ba78 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 38 libxul.so!mozilla::dom::Function::Call [FunctionBinding.cpp:00f781f21da3 : 37 + 0xc] 06:40:51 INFO - eip = 0xb25eecce esp = 0xbfe0bb00 ebp = 0xbfe0bbe8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0bb68 edi = 0xbfe0bb58 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 39 libxul.so!nsGlobalWindow::RunTimeoutHandler [FunctionBinding.h:00f781f21da3 : 70 + 0x1c] 06:40:51 INFO - eip = 0xb1e1efd6 esp = 0xbfe0bbf0 ebp = 0xbfe0bdb8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0bc78 edi = 0xbfe0bc60 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 40 libxul.so!nsGlobalWindow::RunTimeout [nsGlobalWindow.cpp:00f781f21da3 : 12455 + 0x9] 06:40:51 INFO - eip = 0xb1e1f778 esp = 0xbfe0bdc0 ebp = 0xbfe0be38 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x9819e470 edi = 0x95d65800 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 41 libxul.so!nsGlobalWindow::TimerCallback [nsGlobalWindow.cpp:00f781f21da3 : 12701 + 0x1c] 06:40:51 INFO - eip = 0xb1e1f875 esp = 0xbfe0be40 ebp = 0xbfe0be68 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0be5c edi = 0x97871510 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 42 libxul.so!nsTimerImpl::Fire [nsTimerImpl.cpp:00f781f21da3 : 521 + 0xb] 06:40:51 INFO - eip = 0xb129206b esp = 0xbfe0be70 ebp = 0xbfe0bee8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x978a0174 edi = 0xb1e1f842 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 43 libxul.so!nsTimerEvent::Run [TimerThread.cpp:00f781f21da3 : 286 + 0x11] 06:40:51 INFO - eip = 0xb128ff87 esp = 0xbfe0bef0 ebp = 0xbfe0bf38 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa36512f0 edi = 0xa3651308 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 44 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:00f781f21da3 : 1058 + 0x14] 06:40:51 INFO - eip = 0xb128b645 esp = 0xbfe0bf40 ebp = 0xbfe0bfb8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xb713dc00 edi = 0xb60da358 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 45 libxul.so!NS_ProcessNextEvent [nsThreadUtils.cpp:00f781f21da3 : 290 + 0x10] 06:40:51 INFO - eip = 0xb12b34d3 esp = 0xbfe0bfc0 ebp = 0xbfe0bff8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaf74adf0 edi = 0xb713a6e0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 46 libxul.so!mozilla::ipc::MessagePump::Run [MessagePump.cpp:00f781f21da3 : 96 + 0xc] 06:40:51 INFO - eip = 0xb163ec27 esp = 0xbfe0c000 ebp = 0xbfe0c048 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xaf74adf0 edi = 0xb713a6e0 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 47 libxul.so!MessageLoop::RunInternal [message_loop.cc:00f781f21da3 : 232 + 0x14] 06:40:51 INFO - eip = 0xb1619a7c esp = 0xbfe0c050 ebp = 0xbfe0c078 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xb713a6e0 edi = 0xb713dc00 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 48 libxul.so!MessageLoop::Run [message_loop.cc:00f781f21da3 : 225 + 0x8] 06:40:51 INFO - eip = 0xb1619aa2 esp = 0xbfe0c080 ebp = 0xbfe0c0a8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xb713a6e0 edi = 0xb713dc00 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 49 libxul.so!nsBaseAppShell::Run [nsBaseAppShell.cpp:00f781f21da3 : 156 + 0xe] 06:40:51 INFO - eip = 0xb2f4c09b esp = 0xbfe0c0b0 ebp = 0xbfe0c0d8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa936b4c0 edi = 0xb713dc00 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 50 libxul.so!nsAppStartup::Run [nsAppStartup.cpp:00f781f21da3 : 284 + 0x9] 06:40:51 INFO - eip = 0xb37defe9 esp = 0xbfe0c0e0 ebp = 0xbfe0c0f8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xa9380fa0 edi = 0xbfe0c389 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 51 libxul.so!XREMain::XRE_mainRun [nsAppRunner.cpp:00f781f21da3 : 4290 + 0x16] 06:40:51 INFO - eip = 0xb3840796 esp = 0xbfe0c100 ebp = 0xbfe0c1f8 ebx = 0xb60d6558 06:40:51 INFO - esi = 0x00000000 edi = 0xbfe0c389 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 52 libxul.so!XREMain::XRE_main [nsAppRunner.cpp:00f781f21da3 : 4417 + 0x9] 06:40:51 INFO - eip = 0xb3840c4a esp = 0xbfe0c200 ebp = 0xbfe0c258 ebx = 0xb60d6558 06:40:51 INFO - esi = 0xbfe0c290 edi = 0x00000000 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 53 libxul.so!XRE_main [nsAppRunner.cpp:00f781f21da3 : 4508 + 0x6] 06:40:51 INFO - eip = 0xb3840ef7 esp = 0xbfe0c260 ebp = 0xbfe0c398 ebx = 0x08070970 06:40:51 INFO - esi = 0xbfe0c290 edi = 0xb7101680 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 54 firefox!do_main [nsBrowserApp.cpp:00f781f21da3 : 259 + 0x14] 06:40:51 INFO - eip = 0x0804cbb7 esp = 0xbfe0c3a0 ebp = 0xbfe0d3f8 ebx = 0x08070970 06:40:51 INFO - esi = 0xbfe0d504 edi = 0xb7101680 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 55 firefox!main [nsBrowserApp.cpp:00f781f21da3 : 392 + 0x10] 06:40:51 INFO - eip = 0x0804bf55 esp = 0xbfe0d400 ebp = 0xbfe0d458 ebx = 0x08070970 06:40:51 INFO - esi = 0xbfe0d504 edi = 0xbfe0d51c 06:40:51 INFO - Found by: call frame info 06:40:51 INFO - 56 libc-2.15.so + 0x194d3 06:40:51 INFO - eip = 0xb74124d3 esp = 0xbfe0d460 ebp = 0x00000000 06:40:51 INFO - Found by: previous frame's frame pointer 06:40:51 INFO - 57 firefox!__libc_csu_fini + 0x10 06:40:51 INFO - eip = 0x080663c0 esp = 0xbfe0d464 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 58 libc-2.15.so + 0x194d3 06:40:51 INFO - eip = 0xb74124d3 esp = 0xbfe0d470 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 59 libc-2.15.so + 0x1a4ff4 06:40:51 INFO - eip = 0xb759dff4 esp = 0xbfe0d498 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 60 firefox!_GLOBAL__sub_I_TimeStamp.cpp [TimeStamp.cpp:00f781f21da3 : 92 + 0x5] 06:40:51 INFO - eip = 0x0804c1c0 esp = 0xbfe0d4c0 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 61 ld-2.15.so + 0x146b0 06:40:51 INFO - eip = 0xb77276b0 esp = 0xbfe0d4c8 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 62 libc-2.15.so + 0x193e9 06:40:51 INFO - eip = 0xb74123e9 esp = 0xbfe0d4cc ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 63 ld-2.15.so + 0x20ff4 06:40:51 INFO - eip = 0xb7733ff4 esp = 0xbfe0d4d0 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 64 firefox!_GLOBAL__sub_I_TimeStamp.cpp [TimeStamp.cpp:00f781f21da3 : 92 + 0x5] 06:40:51 INFO - eip = 0x0804c1c0 esp = 0xbfe0d4d8 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 65 firefox!_start + 0x21 06:40:51 INFO - eip = 0x0804c1e1 esp = 0xbfe0d4e0 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 66 firefox!init [replace_malloc.c:00f781f21da3 : 133 + 0x5] 06:40:51 INFO - eip = 0x0804bee4 esp = 0xbfe0d4e4 ebp = 0x00000000 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 67 firefox!__libc_csu_fini + 0x10 06:40:51 INFO - eip = 0x080663c0 esp = 0xbfe0d4f0 ebp = 0xbfe0d504 06:40:51 INFO - Found by: stack scanning 06:40:51 INFO - 68 0xbfe0dbc1 06:40:51 INFO - eip = 0xbfe0dbc1 esp = 0xbfe0d50c ebp = 0xbfe0db8c 06:40:51 INFO - Found by: previous frame's frame pointer 06:40:51 INFO - 69 0x2f73646c 06:40:51 INFO - eip = 0x2f73646c esp = 0xbfe0db94 ebp = 0x6975622f 06:40:51 INFO - Found by: previous frame's frame pointer

For the record, there's a big heap of timeouts in html/syntax/parsing that I suspect are related to this too.

I expect all the "see also" are dups of this bug. Anyway, frame 1 says we're at https://hg.mozilla.org/mozilla-central/file/00f781f21da3/js/src/jsobj.cpp#l1089 which looks like this: JS_CopyPropertiesFrom(JSContext* cx, HandleObject target, HandleObject obj) { JSAutoCompartment ac(cx, obj); Frame 2 says we got there from https://hg.mozilla.org/mozilla-central/file/00f781f21da3/dom/bindings/BindingUtils.cpp#l2110 which looks like this: if (!JS_CopyPropertiesFrom(aCx, propertyHolder, copyFrom)) { So the gray thing is the third arg to JS_CopyPropertiesFrom, and it's the copyFrom variable in ReparentWrapper. That comes from here: JS::Rooted<JSObject*> copyFrom(aCx, isProxy ? expandoObject : aObj); Frame 3 shows that aObj comes from https://hg.mozilla.org/mozilla-central/file/00f781f21da3/dom/html/nsHTMLDocument.cpp#l1641 which is doing: rv = mozilla::dom::ReparentWrapper(cx, wrapper); and hence aObj is an HTMLDocument object. So isProxy is very much true. Hence copyFrom is expandoObject, which came from DOMProxyHandler::GetAndClearExpandoObject(aObj), which comes from the expando-and-generation thing, again because this is an HTMLDocument. Now at least right before we called ReparentWrapper, aObj was already not gray. You can tell because the JSAutoCompartment in the ReparentWrapper caller did not do the fatal assert thing, and also because it came from a GetWrapper call and nsWrapperCache::GetWrapper calls ExposeObjectToActiveJS. But if aObj is not gray, its expando should not be gray either. That was the whole point of the changes in bug 1288581! Before we did that we were hitting the asserts here for sure, because the expando could in fact be gray while the object itself was not. But now this really shouldn't be happening afaict. :(

> I expect all the "see also" are dups of this bug. Er, the ones that are assert failures like bug 1296775. The others are crashes in gc, which indicates something bad is happening somewhere....

But I suppose the others could be UFCs if we're messing up our gc bits somehow... So it's possible they have the same underlying cause.

Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.

Wait. Wait. This is an actual crash, not an assertion failure. As in, the arg we got passed (the expando) is in fact bogus/dead/whatever??? Or am I misreading the logs?

I suppose this could be a regression from bug 1288581 or something...

[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: Crashes that look really bad; we don't want to ship these. OK, I did a try run with some more logging, and copyFrom is in fact an expando object, no surprise. Nothing in sight is gray (neither the wrapper nor the expando). We're crashing in the JSAutoCompartment ctor calling compartment() on the given object. In this case that would be the expando, I believe: JS_CopyPropertiesFrom enters the compartment of its last arg, which in this case is the expando object. All of which suggests that the expando object died somehow or something. Which _really_ makes me wonder whether the fix for bug 1288581 is working right.... :( Are we somehow failing to trace the expando?

I agree with your evaluation. JSObject::compartment should look up the group, then the group will return its compartment_ field. So we could go off the rails if the expando was finalized, it's group was finalized, or if either one is in a relocated state. The crash address is high, but looks like a normal address. The offset from chunk alignment should put it in the middle of some arena. I wish we had register values to look at; might tell us if anything is poisoned. Or maybe not as it's x86. I think the nearest plausible cause is indeed bug 1288581. My experience has been that if the simple and obvious thing doesn't work, it's generally because there's already a bug elsewhere, however.

For what it's worth I've done several try runs trying to reproduce this crash. I can reproduce it pretty easily on Linux debug in any sort of recent-ish revision, but NOT with the revision right after bug 1288581 landed. I'm bisecting on try now to see whether that gives us any sort of useful information (presumably about which changeset started triggering some sort of underlying problem which was probably preexisting...)

Lots of try pushes and retriggering bisecting later.... On try, this crash and related ones are easier to reproduce with more recent builds, but I did manage to reproduce it (well the one in html5lib_doctype01.html?run_type=write_single) with the build that has all the patches from bug 1288581. I have not yet been able to reproduce on try with the build that has the first patch from bug 1288581 but not the second, or any builds from before bug 1288581. All the builds I've tried after bug 1288581 do reproduce. So something is in fact quite broken here. Back to trying to get this in rr... Worst-case, we could disable the gray asserts on 50 and back out bug 1288581 there for now. :(

OK, with some printfs on try pushes and a conversation with terrence, we think we understand what's going on here. The sequence of events is this: 1) A GC starts. 2) Document's Trace function is called, it adds the reflector/wrapper to the "mark this gray" list. 3) GC slice finishes. Marking is not done yet. 4) document.open is called, we go to reparent the document's reflector. 5) We GetAndClearExpandoObject() the expando from the reflector. 6) Reparenting triggers another GC slice (via JS_CloneObject). 7) We trace the reflector, hit its trace hook, but it doesn't have an expando anymore. 8) GC finishes up, expando never got traced, it gets swept. 9) We unwind back to reflector reparenting, but now our expando is dead. This used to not fail because before bug 1288581 we added the expando to the "mark this gray" list in step 2, so the GC knew it was alive. But now we rely on the reflector tracing it, which it fails to do, per step 7. And the fact that we put the expando in a Rooted in step 5 doesn't matter, because Rooted got traced back in step 1. The way this normally works, apparently (e.g. for slot storage in the JS engine) is that when a reference is _removed_ the object that used to be referenced is marked black (pre barrier) just in case someone else is referencing it somewhere with a reference that was created after the somewhere was traced. Unfortunately, we don't store the expando in a slot, so when we remove the reference to it in step 5 the GC doesn't know we did that. And the answer is that we need to pre-barrier in GetAndClearExpandoObject.

This should also fix bug 1296775 and bug 1290359. There's a very good chance it will also fix bug 1293386, bug 1292855, and bug 1289452: those would get hit if we happened to start _another_ gc after the expando died but while it was still in the Rooted. All of them seem to be dying under the domClass->mGetProto call, which could finish up a GC that kills the expando and then do _another_ one, causing the Rooted to try to mark a dead object.

Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a4ef0b5b78cb Make sure we expose the expando of a [OverrideBuiltins] proxy to active JS when it gets cleared from the proxy. r=terrence

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/88a081d149b5 for jsreftest crashes, for which bz has the decent stacks since inbound was symbol-free at the time.

For some values of "decent"... https://treeherder.mozilla.org/#/jobs?repo=try&revision=afb181e45ffd shows the crashes (J6 and J7). J6 claims a 2-deep stack with UnmarkGrayTracer::onChild calling js::CurrentThreadCanAccessRuntime which then crashes. No hint of who called onChild. J7 shows a 719-frame-deep stack starting with UnmarkGrayTracer::onChild (kinda) and then calling JSObject::traceChildren, js::TraceRange<JS::Value>, DispatchToTracer<JS::Value>, DoCallback<JS::Value>, DoCallback<JSObject*>, JS::CallbackTracer::onObjectEdge, and back to UnmarkGrayTracer::onChild and so on in a loop. Is it possible we're actually hitting a stack overflow while doing unmark gray stuff? That could at least in theory explain why it's OS-specific and debug-specific... but not why we don't hit it all the time! Terrence, is recursion like that with UnmarkGrayTracer expected?

OK. So I still don't understand the Android crashes in terms of why we crash. But I do know how to avoid them, kinda: stop doing the unmarkgray under nsWrapperCache::ReleaseWrapper (which currently also calls GetAndClearExpandoObject, which I had missed). Let's do that and I'll think a bit more about why we're crashing on Android there.

Oh, sfink says that gray unmarking _can_ in fact run up against stack limits. UnmarkGrayTracer::onChild has this bit: if (!JS_CHECK_STACK_SIZE(cx->nativeStackLimit[StackForSystemCode], &stackDummy)) { /* stuff */ } I wonder whether our stack size checks are broken on debug android....

This should also fix bug 1296775 and bug 1290359. There's a very good chance it will also fix bug 1293386, bug 1292855, bug 1289452, and bug 1303340: those would get hit if we happened to start _another_ gc after the expando died but while it was still in the Rooted. All of them seem to be dying under the domClass->mGetProto call, which could finish up a GC that kills the expando and then do _another_ one, causing the Rooted to try to mark a dead object.

Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f34b21bf3c86 Make sure we expose the expando of a [OverrideBuiltins] proxy to active JS when it gets cleared from the proxy. r=peterv

I filed bug 1303461 on the debug android issue and my suspicion that our stack size accounting there is broken.

Comment on attachment 8792083 [details] [diff] [review] Make sure we expose the expando of a [OverrideBuiltins] proxy to active JS when it gets cleared from the proxy Approval Request Comment [Feature/regressing bug #]: Bug 1288581 [User impact if declined]: "Random" crashes while doing GC. [Describe test coverage new/current, TreeHerder]: We have tests that were triggering this, albeit intermittently. [Risks and why]: I think this is reasonably low risk. The other option is described in comment 14, and would be of comparable risk at least. [String/UUID change made/needed]: None.

Comment on attachment 8792083 [details] [diff] [review] Make sure we expose the expando of a [OverrideBuiltins] proxy to active JS when it gets cleared from the proxy 50 moved to Beta today.

(In reply to Boris Zbarsky [:bz] (TPAC) from comment #19) > For some values of "decent"... > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=afb181e45ffd shows > the crashes (J6 and J7). J6 claims a 2-deep stack with > UnmarkGrayTracer::onChild calling js::CurrentThreadCanAccessRuntime which > then crashes. No hint of who called onChild. > > J7 shows a 719-frame-deep stack starting with UnmarkGrayTracer::onChild > (kinda) and then calling JSObject::traceChildren, js::TraceRange<JS::Value>, > DispatchToTracer<JS::Value>, DoCallback<JS::Value>, DoCallback<JSObject*>, > JS::CallbackTracer::onObjectEdge, and back to UnmarkGrayTracer::onChild and > so on in a loop. > > Is it possible we're actually hitting a stack overflow while doing unmark > gray stuff? That could at least in theory explain why it's OS-specific and > debug-specific... but not why we don't hit it all the time! > > Terrence, is recursion like that with UnmarkGrayTracer expected? Yes. UnmarkGray stack depth is generally proportional to the object graph's longest path or cycle. Note that we do have an optimization in place to mark shapes with constant stack, since those are typically just a long linked list [1]. If we do run out of stack, there is the check Steve pointed out to keep us from having to crash. That said, I'm not sure how well tested any of the "gray bits invalid" stuff is in practice. I'd guess it's probably hit occasionally on try, but coverage is spotty. 1- http://searchfox.org/mozilla-central/rev/f6c298b36db67a7109079c0dd7755f329c1d58e2/js/src/gc/Marking.cpp#2913-2917

Comment on attachment 8792083 [details] [diff] [review] Make sure we expose the expando of a [OverrideBuiltins] proxy to active JS when it gets cleared from the proxy Fixes an intermittent failure/crash, Beta50+