Created attachment 360990 [details] example stack from bp-bbb85a7b-61cf-4b9d-a3a2-c3c1e2090206 A new topcrash appeared in the 2009-02-06 nightlies, at js_RecordLoopEdge. Plenty of stacks are available, on all of Windows, Mac, and Linux: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.1b3pre&query_search=signature&query_type=contains&query=&date=&range_value=12&range_unit=hours&do_query=1&signature=js_RecordLoopEdge%28JSContext*%2C%20TraceRecorder*%2C%20unsigned%20int%26%29
Severity: normal → critical
If you can capture the content and make it reproducible, I will look into this today. Reducing is even better, but just capturing is already a great help.
Created attachment 361397 [details] unreduced zipped testcase Unzipping this and loading the page crashes every time for me. Let me know if you can't reproduce and I'll try and do something more with it tomorrow.
I should have mentioned I'm using a shiretoko nightly on Windows - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090209 Shiretoko/3.1b3pre
I am not crashing on the testcase or the original site with TraceMonkey tip. Could you verify using a recent tinderbox build? http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ look for TraceMonkey-* in the directory If you can confirm that this fixes the issue please mark the bug "verified". Otherwise reopen.
Severity: critical → normal
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Priority: -- → P2
Resolution: --- → WORKSFORME
Graydon, could this have been the bug you fixed today? (not flushing cache when deallocating global scripts)
per shaver marking fixed-in-tracemonkey and keep bug open until the next merge instead of fixed/wfm
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #5) > I am not crashing on the testcase or the original site with TraceMonkey tip. > Could you verify using a recent tinderbox build? Sure. I will try that later today.
(In reply to comment #5) > I am not crashing on the testcase or the original site with TraceMonkey tip. > Could you verify using a recent tinderbox build? ... > If you can confirm that this fixes the issue please mark the bug "verified". > Otherwise reopen. Using today's build (from /tracemonkey-win32/1234294148 ) I can confirm that this indeed seems to be fixed. I don't think "verified-in-tracemonkey" exists, so I'll just wait to verify again when this lands on 1.9.1 (and/or trunk).
I see there was just a merge from TM to M-C, but this patch missed the boat ? http://hg.mozilla.org/mozilla-central/rev/1ed5d7300265
Given that this is the top crash by far in the stats (and seems to be happening quite frequently to people in MozillaZine forums as well as me) and a fix exists, it would be good to get it in for beta 3, wouldn't it? (It's currently marked as P2)
Priority: P2 → P1
We should check this with 1-18-2009 builds.
I assume comment #14 means the 2009-02-18 (2-18-2003 given the formating 1-18-2009) builds? If so, then build 2009-02-18 still crashes. Would a backtrace be helpful?
No crashes here using Vista and build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090219 Minefield/3.2a1pre Firefox/3.0.4 ID:20090219014537 changeset: http://hg.mozilla.org/mozilla-central/rev/d9d4bf676f65
The latest build seems to have fixed the problem for me. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090221 Shiretoko/3.1b3pre Should this be marked as closed?
confirmed, latest 1.9.1 build doesn't crash
Well, must have been fixed by one of the collection of tracemonkey fixes that were merged yesterday to 1.9.1, and a couple of days before to trunk - bugs 454184, 456895, 465567, 468782, 469625, 472702, 474801, 475469, 475474, 475479, 475645, 475680, 475761, 475821, 475834, 475916. Maybe someone knows which? Anyway, marking fixed1.9.1 and FIXED
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
I haven't been able to reproduce a crash since installing 2009-02-21-03-mozilla-1.9.1/ 22-Feb-2009 05:27. However, I am getting dialogs reporting "Failed to load script". I'll file this as a separate bug once I have more information.
Follow to comment #23. "Failed to load script" involves NoScript 220.127.116.11 (eg. http://blog.wired.com/27bstroke6; temporary allow while page results in no warning while only allowing wired.com produces warning). Even if this is somehow related to recent checked in work it should be treated as a separate bug. I'll log it as such for now.
No more crash reports on trunk and 1.9.1 for nearly 2 weeks. We can safely mark this as fixed.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.