Closed Bug 454812 Opened 16 years ago Closed 16 years ago

TM: crash on somethingawful.com [@ js_ExecuteTree(JSContext*, nanojit::Fragment**, unsigned int&, nanojit::GuardRecord**)]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: vlad, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

With content jit enabled, visiting http://forums.somethingawful.com/forumdisplay.php?forumid=22 crashes the browser instantly.  http://crash-stats.mozilla.com/report/pending/aaeeac97-8019-11dd-9c04-001cc45a2ce4 is one of the crash reports, if it ever finishes processing.
Signature	js_ExecuteTree(JSContext*, nanojit::Fragment**, unsigned int&, nanojit::GuardRecord**)
UUID	aaeeac97-8019-11dd-9c04-001cc45a2ce4
Time	2008-09-11 08:52:35-07
Uptime	13
Product	Firefox
Version	3.1b1pre
Build ID	20080911020314
OS	Mac OS X
OS Version	10.5.4 9E17
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 10
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x15d51b
Comments	
Crashing Thread
Frame 	Module 	Signature 	Source
0 	libmozjs.dylib 	js_ExecuteTree 	
1 	libmozjs.dylib 	js_MonitorLoopEdge 	
2 	libmozjs.dylib 	js_Interpret 	
3 	libmozjs.dylib 	js_Execute 	
4 	libmozjs.dylib 	JS_EvaluateUCScriptForPrincipals 	
5 	XUL 	nsJSContext::EvaluateString
Keywords: crash
Summary: TM: crash on somethingawful.com → TM: crash on somethingawful.com [@ js_ExecuteTree(JSContext*, nanojit::Fragment**, unsigned int&, nanojit::GuardRecord**)]
Blocks: 451602
Hardware: PC → All
Seems to work with the latest tracemonkey build.

ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/tracemonkey-macosx/1222118468/

Please feel free to re-open if you can reproduce it with the TM builds. We will merge into mozilla trunk soon (24h or so).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Andreas, did the merge happen within the last 6 days? Current nightly builds are still crashing for me when I open the website. Tracemonkey builds are fine.

Shouldn't we wait with closing bugs as WFM until the merge has been done?
Yeah, I agree -- you guys can use fixed-tm or something in status whiteboard so that you can skip bugs that are already fixed in tm, and then mass-close fixed-tm bugs (after verifying) post merge.
Yeah, we usually do that. We were expecting a merge into m-c to be imminent, but it got delayed due to a mochitest failure we are trying to figure out before merging. We won't close user-reported bugs any more until its in m-c.
As we can see bug 456810 is also fixed for current tracemonkey builds but still open. Brendan hasn't marked it fixed after checking in the patch. Let us reopen this one until its clear how to better track these bugs.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Yeah feel free to reopen this one and other similar bugs. Please comment in the bug if you retest after we landed in m-c so I can close it.
Sync with mc happened. Closing bug. Please confirm if possible.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → WORKSFORME
Verified with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002020319

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre ID:20081002033404
Status: RESOLVED → VERIFIED
Crash Signature: [@ js_ExecuteTree(JSContext*, nanojit::Fragment**, unsigned int&, nanojit::GuardRecord**)]
You need to log in before you can comment on or make changes to this bug.