Closed Bug 573558 Opened 15 years ago Closed 15 years ago

Crash in [@ ExecuteTree ]

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+
status1.9.2 --- wanted

People

(Reporter: marcia, Unassigned)

References

(
URL
)

Details

(Keywords: crash, regression, Whiteboard: [sg:critical?])

Crash Data

Seen while reviewing crash stats and reproduced using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a6pre) Gecko/20100621 Minefield/3.7a6pre STR: 1. Load site in URL 2. Crash 100% Does not crash using 3.6.3. http://tinyurl.com/2e2sdqv links to the Mac crashes on trunk. https://crash-stats.mozilla.com/report/index/c71a07f6-6c1a-4e77-9a7a-4a7062100621 is one of my reports. Bug 530955 is an earlier bug that was found with the same stack and was fixed. Frame Module Signature [Expand] Source 0 @0x15213ba0 1 libmozjs.dylib ExecuteTree js/src/jstracer.cpp:6392 2 libmozjs.dylib js::MonitorLoopEdge js/src/jstracer.cpp:7000 3 libmozjs.dylib js_Interpret js/src/jsops.cpp:473 4 libmozjs.dylib js_Invoke js/src/jsinterp.cpp:664 5 libmozjs.dylib js_InternalInvoke js/src/jsinterp.cpp:694 6 libmozjs.dylib JS_CallFunctionValue js/src/jsapi.cpp:4634 7 XUL nsJSContext::CallEventHandler 8 XUL nsJSEventListener::HandleEvent 9 XUL nsEventListenerManager::HandleEventSubType 10 XUL nsEventListenerManager::HandleEventInternal 11 XUL nsEventTargetChainItem::HandleEventTargetChain 12 XUL nsEventDispatcher::Dispatch 13 XUL DocumentViewerImpl::LoadComplete 14 XUL nsDocShell::EndPageLoad 15 XUL nsDocShell::OnStateChange 16 XUL nsDocLoader::FireOnStateChange 17 XUL nsDocLoader::DocLoaderIsEmpty 18 XUL nsDocLoader::OnStopRequest 19 XUL nsLoadGroup::RemoveRequest 20 XUL nsDocument::DoUnblockOnload 21 XUL nsBindingManager::DoProcessAttachedQueue 22 XUL nsRunnableMethodImpl<void 23 XUL nsThread::ProcessNextEvent 24 XUL NS_ProcessPendingEvents_P 25 XUL nsBaseAppShell::NativeEventCallback 26 XUL nsAppShell::ProcessGeckoEvents 27 CoreFoundation __CFRunLoopDoSources0 28 CoreFoundation __CFRunLoopRun 29 CoreFoundation CFRunLoopRunSpecific 30 CoreFoundation CFRunLoopRunInMode 31 HIToolbox RunCurrentEventLoopInMode 32 HIToolbox ReceiveNextEventCommon 33 HIToolbox BlockUntilNextEventMatchingListInMode 34 AppKit _DPSNextEvent 35 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 36 AppKit -[NSApplication run] 37 XUL nsAppShell::Run 38 XUL nsAppStartup::Run 39 XUL XRE_main 40 firefox-bin main browser/app/nsBrowserApp.cpp:158 41 firefox-bin firefox-bin@0xbf5 42 @0x5
winxp as well.
OS: Mac OS X → All
Looks as if it started happening on 6/12. I can try to hunt down the regression range.
Regression window: Works: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100606 Minefield/3.7a5pre, 64 bit (no regular build was available that day) Crash: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100607 Minefield/3.7a5pre Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-06-06+04%3A00%3A00&enddate=2010-06-07+04%3A00%3A00
This signature has a scary stack; things have gone very wrong. https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=ExecuteTree I see 3.6 builds back to late 2009 in that list so I have my doubts about the trunk regression range in comment 3, although maybe there are multiple bugs that result in a bad tree that then later crash when executing it. This stack caught my eye because it started happening to primarily Linux folks in 3.6.13pre and almost no Windows folks, when in previous release builds there have been almost zero linux crashes and tons on Windows (see the Table tab).
Group: core-security
status1.9.2: --- → wanted
Keywords: testcase-wanted
Whiteboard: [sg:critical?]
I no longer am able to crash with that URL using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101116 Firefox/4.0b8pre.
On the home.eease.com urls, I just see the assertion in bug 581776
Marking this a blocker so it doesn't get forgotten.
blocking2.0: --- → betaN+
Does this bug still exist?
Looking at the crash stats query above, I only see a 4.0b1 crash but many 3.6.x crashes. I have a similar crash in 1.9.2 win/mac/linux. It also has a random flash crash on Linux with a memory error that may be the root cause. If you want a new bug filed let me know. http://jprimages.com/soccer/2010girls/vbhs/satellite/10-26-10/h32c73e1c#h32c73e1c 1.9.2 Linux Program received signal SIGTRAP, Trace/breakpoint trap. JS_Assert (s=0x37cbb4 "HAS_FUNCTION_CLASS(callee)", file=0x37ab74 "/work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp", ln=5263) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsutil.cpp:69 69 abort(); (gdb) bt #0 JS_Assert (s=0x37cbb4 "HAS_FUNCTION_CLASS(callee)", file=0x37ab74 "/work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp", ln=5263) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsutil.cpp:69 #1 0x002f026c in SynthesizeFrame (cx=0x8efb5f0, fi=..., callee=0xa029328) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:5263 #2 0x002f3d67 in LeaveTree (state=..., lr=0xa1675ac) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6494 #3 0x002f3347 in ExecuteTree (cx=0x8efb5f0, f=0xa0d47ac, inlineCallCount=@0xbfffc9e4, innermostNestedGuardp=0xbfffc81c) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6292 #4 0x002f47bc in js_MonitorLoopEdge (cx=0x8efb5f0, inlineCallCount=@0xbfffc9e4) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6749 #5 0x00230d61 in js_Interpret (cx=0x8efb5f0) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsops.cpp:904 #6 0x00250a98 in js_Invoke (cx=0x8efb5f0, argc=1, vp=0x9405e20, flags=0) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsinterp.cpp:1368 A different run on Linux 1.9.2 gives: Program received signal SIGSEGV, Segmentation fault. 0x004d5d3b in LeaveTree (state=..., lr=0x94152dc) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6491 6491 JSObject* callee = *(JSObject**)&stack[calleeOffset]; (gdb) bt #0 0x004d5d3b in LeaveTree (state=..., lr=0x94152dc) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6491 #1 0x004d5347 in ExecuteTree (cx=0x8f8cf08, f=0x9c61e14, inlineCallCount=@0xbfffcb70, innermostNestedGuardp=0xbfffc9a8) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6292 #2 0x004d67bc in js_MonitorLoopEdge (cx=0x8f8cf08, inlineCallCount=@0xbfffcb70) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6749 #3 0x00412d61 in js_Interpret (cx=0x8f8cf08) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsops.cpp:904 #4 0x00432a98 in js_Invoke (cx=0x8f8cf08, argc=1, vp=0x9449360, flags=0) at /work/mozilla/builds/1.9.2/mozilla/js/src/jsinterp.cpp:1368 1.9.2 Mac Intel 10.5 Reason: KERN_PROTECTION_FAILURE at address: 0x0000001d 0x003c95ef in LeaveTree (state=@0xbfff8b30, lr=0x657b0f4) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6490 6490 calleeOffset += callstack[n]->callerHeight; (gdb) bt #0 0x003c95ef in LeaveTree (state=@0xbfff8b30, lr=0x657b0f4) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6490 #1 0x003d0de1 in ExecuteTree (cx=0x664f800, f=0x61a863c, inlineCallCount=@0xbfffc130, innermostNestedGuardp=0xbfffbd88) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6292 #2 0x003edb6d in js_MonitorLoopEdge (cx=0x664f800, inlineCallCount=@0xbfffc130) at /work/mozilla/builds/1.9.2/mozilla/js/src/jstracer.cpp:6749 #3 0x003034ea in js_Interpret (cx=0x664f800) at jsops.cpp:904 #4 0x00324c8a in js_Invoke (cx=0x664f800, argc=1, vp=0x6688e20, flags=0) at jsinterp.cpp:1368 # 1.9.1 Linux crashes with an unrelated stack, 1.9.2 Linux does not. 1.9.1, 2.0.0 Mac do not crash
(In reply to comment #9) > 1.9.2 Linux does not. should have read 2.0.0 Linux does not.
OK, bc says *this* bug, which blocks 2.0, no longer exists. bc, feel free to file new bugs on the related issues you found in 1.9.2.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Group: core-security
Crash Signature: [@ ExecuteTree ]
You need to log in before you can comment on or make changes to this bug.