Closed
Bug 500936
Opened 15 years ago
Closed 15 years ago
top crash [@ js_MonitorLoopEdge(JSContext*, unsigned int&)]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
status1.9.1 | --- | wanted |
People
(Reporter: samuel.sidler+old, Assigned: automation)
References
Details
(Keywords: crash, Whiteboard: [sg:critical?])
Crash Data
Attachments
(1 file)
383.73 KB,
text/plain
|
Details |
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.
Flags: wanted1.9.1.x?
Flags: blocking1.9.1.1?
Reporter | ||
Comment 2•15 years ago
|
||
gal: Can I assign this to you since you worked on and investigated bug 499169?
Assignee: general → gal
Reporter | ||
Comment 3•15 years ago
|
||
(This crash is currently #37 on the topcrash list for Firefox 3.5.)
Flags: wanted1.9.1.x? → wanted1.9.1.x+
Comment 4•15 years ago
|
||
I will need urls and some help reproducing if we want to fix this one.
Comment 5•15 years ago
|
||
Are we sure this is still active with the fixes we have lined up for 3.5.1?
Comment 6•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
Well if the bug is fixed, I will gladly take possession of the dead corpse =)
Comment 8•15 years ago
|
||
eew!
Reporter | ||
Comment 9•15 years ago
|
||
(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=
Comment 10•15 years ago
|
||
(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.
Comment 11•15 years ago
|
||
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.
Updated•15 years ago
|
Comment 12•15 years ago
|
||
I will give the instructions a try. Thanks Martin.
Comment 13•15 years ago
|
||
A (potential) testcase might be at bug 503620, it's already turned security-sensitive.
Depends on: 503620
Comment 14•15 years ago
|
||
Gary, is this a dup of 503620?
Reporter | ||
Updated•15 years ago
|
Flags: wanted1.9.1.x+
Comment 16•15 years ago
|
||
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.
Reporter | ||
Comment 17•15 years ago
|
||
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.
Comment 20•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #396098 -
Attachment mime type: application/octet-stream → text/plain
Comment 24•15 years ago
|
||
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.
Reporter | ||
Comment 26•15 years ago
|
||
Any update here?
Comment 27•15 years ago
|
||
No longer in the top 100, but still 400+ crashes a week.
blocking1.9.1: needed → ---
Keywords: topcrash
Comment 28•15 years ago
|
||
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...
Whiteboard: [sg:critical?]
(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).
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ js_MonitorLoopEdge(JSContext*, unsigned int&)]
Assignee | ||
Updated•9 years ago
|
Assignee: gal → automation
Assignee | ||
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•