This bug is to track the remaining topcrash (probably top 25, but not #1) from bug 499169 that happens with a stack signature of js_MonitorLoopEdge(JSContext*, unsigned int&). In bug 499169, we fixed the #1 topcrash with this signature. However there is still a lingering crash with this signature that we should investigate. Currently, this signature is #10 overall for Firefox 3.5 and dropping, as users move to RC3. The stack looks the same as bug 499169. This is taken from bp-245f389e-4398-48c4-b46d-c7f142090627: Crashing Thread Frame Module Signature [Expand] Source 0 @0xf959950 1 @0x12dc7b 2 js3250.dll js_MonitorLoopEdge js/src/jstracer.cpp:4862 3 js3250.dll js_Interpret js/src/jsinterp.cpp:3308 It's unclear where this crash will be in the topcrash list, but it *certainly* won't be #1 and will probably end closer to #20, if I'm following the trends right. Some comments: > When firebug is open, and the browser is refreshed there is a high chance of > a crash > submitting froms crashed FX again > what's up with GMail checkboxes issues?! O_O > I was just checking boxes in gmail too fast O.o > I refresh a page that I just made a HTML edit to and the browser crashes. > checkboxes in GMail seems to explode with the browser if you would irritate > them with very fast clicks =D > После инспекта страницы фаербагом, Fx рухнул. Which roughly translates to: > After inspecting pages, Fx crashed. From the few comments we have, most people seem to be crashing when using Gmail and forms.

gal: Can I assign this to you since you worked on and investigated bug 499169?

(This crash is currently #37 on the topcrash list for Firefox 3.5.)

I will need urls and some help reproducing if we want to fix this one.

Are we sure this is still active with the fixes we have lined up for 3.5.1?

I haven't been able to reproduce this with the crash urls for Firefox 3.5 from 2009-07-01. crash-stats doesn't have a report for 3.5.1pre afaict.

Well if the bug is fixed, I will gladly take possession of the dead corpse =)

eew!

(In reply to comment #6) > I haven't been able to reproduce this with the crash urls for Firefox 3.5 from > 2009-07-01. crash-stats doesn't have a report for 3.5.1pre afaict. Just because it doesn't show in the list doesn't mean you can't query for it, just have to modify the URL: http://crash-stats.mozilla.com/query/query?do_query=1&product=Firefox&version=Firefox%3A3.5.1pre&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=

(In reply to comment #6) > I haven't been able to reproduce this with the crash urls for Firefox 3.5 from > 2009-07-01. crash-stats doesn't have a report for 3.5.1pre afaict. Url isn't important from my experience with this bug. Try the reports from bug 502053. What I've seen is that it's related to reloading/reflow of the page in some way. After using Firebug (inspect maybe related, not positive) if I click reload it crashes, if I go to the address bar and hit enter (as new request) no crash occurs.

I can pretty much reproduce this on demand using Firebug in 3.5 and 3.5.1pre (20090714052038) - At https://cp.10tb.com/ if you inspect the page (with firebug) and change elements id or heights or something and hit refresh, it crashes in both versions. I'm sure I've seen it crash without messing around in firebug, but it's a good way of producing the same error. 7cdaab70-6ae0-4f92-825d-edb9d2090714 e9b3ff11-4cf5-478d-8292-3df0e2090714 4d945dbd-d161-4ca0-ba05-2be0a2090714 Are just some of mine.

I will give the instructions a try. Thanks Martin.

A (potential) testcase might be at bug 503620, it's already turned security-sensitive.

Gary, is this a dup of 503620?

I am just going to be paranoid here.

ss: are we planning to take this on a 1.9.1.x build? I see it says needed up there. I have a contributor who says he can reproduce this (but there's no telling if he's got the same crash or just another jit crash). He's going to email me a reduced test case which I'll attach here if I get it.

Clint: If we get a patch, we definitely want to take this for 1.9.1.x. The patch in bug 503080 (which fixes the testcase in bug 503620) is rather large and not targeted and likely not suitable for 1.9.1.x.

I can reproduce by: 1. Loading http://www.comcast.net 2. Acknowledging the "incompatible browser" warning 3. Clicking on any of the "Top Videos" Report here: http://crash-stats.mozilla.com/report/index/bp-0d8021c0-68d1-45d3-9854-ac71e2090821 Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090820 Minefield/3.7a1pre (.NET CLR 3.5.30729)

FWIW, the same steps in comment 18 are crashing me on the 1.9.2 branch, but in a different stack (js_Invoke); filed that as bug 511831.

Stephen, I cannot get it to crash. Would you be able to get a stack trace with windbg for both of the crashes? See https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

No.

Sorry for my terse comment 21; I hope the WinDbg output in comment 22 is helpful; I also have it in my VM as a save/restore point, for others to look at in the office on Monday.

Can you grab me monday? I would like to see the save/restore point.

(In reply to comment #24) > Can you grab me monday? I would like to see the save/restore point. Sure.

Any update here?

No longer in the top 100, but still 400+ crashes a week.

Cannot reproduce using Stephen's comment 18 steps. Tried using Firefox 3.6, Firefox 3.5.7, and trunk debug build on Windows. Crash-stats still shows 93 crashes in the past week. Stephen, can you still reproduce this? We're crashing calling nearly random addresses. Setting to critical for now...

(In reply to comment #28) > Cannot reproduce using Stephen's comment 18 steps. Tried using Firefox 3.6, > Firefox 3.5.7, and trunk debug build on Windows. Crash-stats still shows 93 > crashes in the past week. Stephen, can you still reproduce this? > > We're crashing calling nearly random addresses. Setting to critical for now... Hey Brandon; sorry, I can't reproduce any longer. iirc, when I showed this to Andreas, he saw the crash but said he thought it was another bug that was going to get fixed soon (and apparently it did).