If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

crashes [@ js_RecordLoopEdge]

VERIFIED FIXED in mozilla1.9.2a1



JavaScript Engine
9 years ago
6 years ago


(Reporter: dbaron, Assigned: gal)


(4 keywords)

crash, regression, topcrash, verified1.9.1
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fixed-in-tracemonkey, crash signature, URL)


(2 attachments)

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:

Comment 1

9 years ago
I seem to be hitting this quite a lot on wowhead.com

In particular, I crash every time at http://www.wowhead.com/?achievement=2557 . I could have a go at reducing the page if that would help, but there's 200K of javascript there...

I don't crash on that page with tracemonkey disabled.
Severity: normal → critical

Comment 2

9 years ago
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.

Comment 3

9 years ago
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.

Comment 4

9 years ago
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

Comment 5

9 years ago
I am not crashing on the testcase or the original site with TraceMonkey tip. Could you verify using a recent tinderbox build?


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
Last Resolved: 9 years ago
Flags: blocking1.9.1?
Priority: -- → P2
Resolution: --- → WORKSFORME

Comment 6

9 years ago
Graydon, could this have been the bug you fixed today? (not flushing cache when deallocating global scripts)

Comment 7

9 years ago
per shaver marking fixed-in-tracemonkey and keep bug open until the next merge instead of fixed/wfm
Resolution: WORKSFORME → ---
Whiteboard: fixed-in-tracemonkey

Comment 8

9 years ago
(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.


9 years ago
Flags: blocking1.9.1? → blocking1.9.1+

Comment 9

9 years ago
(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 ?


Comment 11

9 years ago
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)

Comment 12

9 years ago
Priority: P2 → P1


9 years ago
Severity: normal → critical


9 years ago
Assignee: general → gal


9 years ago
Duplicate of this bug: 478210


9 years ago

Comment 14

9 years ago
We should check this with 1-18-2009 builds.
Duplicate of this bug: 478860

Comment 16

9 years ago
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


9 years ago
Duplicate of this bug: 479369
Javascript menus @ www.incidentpage.net crashes Firefox 3.1b3pre:


Looks like it might be part of this bug.

Comment 20

9 years ago
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?

Comment 21

9 years ago
confirmed, latest 1.9.1 build doesn't crash

Comment 22

9 years ago
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
Keywords: fixed1.9.1


9 years ago
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED

Comment 23

9 years ago
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.

Comment 24

9 years ago
Follow to comment #23. "Failed to load script" involves NoScript (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.
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: --- → mozilla1.9.2a1
Crash Signature: [@ js_RecordLoopEdge]
You need to log in before you can comment on or make changes to this bug.