Closed Bug 537630 Opened 15 years ago Closed 14 years ago

crash [@ nsJSScriptTimeoutHandler::SetLateness(unsigned int)]

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9.3a5
Tracking Status
status1.9.2 --- .7-fixed

People

(Reporter: wsmwk, Assigned: timeless)

References

Details

(Keywords: crash, Whiteboard: [qa-ntd-192])

Crash Data

Attachments

(1 file, 1 obsolete file)

crash [@ nsJSScriptTimeoutHandler::SetLateness(unsigned int)]

bp-a33a7bbd-580d-495c-87ac-96e412100103 has almost no extensions
0	xul.dll	nsJSScriptTimeoutHandler::SetLateness	 dom/base/nsJSTimeoutHandler.cpp:301
1	xul.dll	nsGlobalWindow::RunTimeout	dom/base/nsGlobalWindow.cpp:8120
2	xul.dll	nsGlobalWindow::TimerCallback	dom/base/nsGlobalWindow.cpp:8473
3	xul.dll	nsTimerImpl::Fire	xpcom/threads/nsTimerImpl.cpp:427
4	nspr4.dll	_PR_MD_UNLOCK	nsprpub/pr/src/md/windows/w95cv.c:344
5	xul.dll	nsTimerEvent::Run	xpcom/threads/nsTimerImpl.cpp:519
6	xul.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527
7	xul.dll	NS_ProcessNextEvent_P	obj-firefox/xpcom/build/nsThreadUtils.cpp:250
8	xul.dll	nsXULWindow::ShowModal	xpfe/appshell/src/nsXULWindow.cpp:407
9	xul.dll	nsContentTreeOwner::ShowAsModal	xpfe/appshell/src/nsContentTreeOwner.cpp:528
10	xul.dll	nsWindowWatcher::OpenWindowJSInternal	


hotmail users
bp-93b8fe2f-4dee-4403-8ca9-d608f2091225
bp-109ec996-d9a6-4d27-84f0-d15292091216

yahoo
bp-95217bc4-88a7-4c48-9467-297322091204
Frame	Module	Signature [Expand]	Source
0	xul.dll	nsJSScriptTimeoutHandler::SetLateness	dom/src/base/nsJSTimeoutHandler.cpp:301
1	xul.dll	nsGlobalWindow::RunTimeout	dom/src/base/nsGlobalWindow.cpp:7809
2	xul.dll	nsGlobalWindow::TimerCallback	dom/src/base/nsGlobalWindow.cpp:8152
3	xul.dll	nsTimerImpl::Fire	xpcom/threads/nsTimerImpl.cpp:420 
https://crash-stats.mozilla.com/report/index/
Any updates on this?
(In reply to comment #1)
> Any updates on this?

Someone else will have to give you an update. I merely bugified what is currently #64 crash for FF 3.6.2 (probably in the context at looking at other js scripty problems), and also occurs on trunk **. 


** http://crash-stats.mozilla.com/report/list?product=Firefox&branch=1.9.3&query_search=signature&query_type=exact&query=nsJSScriptTimeoutHandler%3A%3ASetLateness%28unsigned%20int%29&date=&range_value=4&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=nsJSScriptTimeoutHandler%3A%3ASetLateness%28unsigned%20int%29
Component: General → XUL
QA Contact: general → xptoolkit.widgets
I have been getting this bug a GREAT deal lately - multiple crashes a day. Today I learned how to read the bug reports here and I think I can help! :-)

This seems to happen most often when Flash is displayed on the page. I use Flashblocker but when I look at something, particularly an embedded YouTube vid, I often crash. It has also occurred on pages with no apparent Flash like NewEgg's checkout page. <cough> I have from time to time found the Ajax links on FaceBook non-functional, Javascript crashing I suspected. I often run MANY open pages and MANY open tabs. 54windows, 240tabs right now.

Today after another crash I began digging into my bug reports, I wanted to know where they went and WTF. Seeing Java mentioned a great deal here and this bug in particular popping I checked my plug-ins. Java was listed as "okay" but was ONe point rev behind. R18 with R19 being most current I believe. Flash was also a minor point rev old. I updated both of these!

I have now watched about 8 YouTube vids in a row. Something that would normally have caused my browser to become non-responsive, choke, and die. I am not sure which of the two updates may have effected this but as of right now I *appear* to be stable again. Hrm, naturally it's starting to flake as I type this. <sigh> At least it's coming back right now - fingers crossed! I'll try to keep this up to date if this is "fixed" or not for me and can answer questions\try things if devs would like.
Component: XUL → DOM
QA Contact: xptoolkit.widgets → general
Nope, still crashes :(
Is there some kind of steps to reproduce for this?

morejunk4me@hotmail.com, you're sure you're seeing this bug?
(In reply to comment #5)
> Is there some kind of steps to reproduce for this?
> 
> morejunk4me@hotmail.com, you're sure you're seeing this bug?

about:crashes resolves to this bug pretty regularly. Honestly to me it looks like an issue with Flash since when I unblock a Flash item such as a video on Youtube it often seems to manifest itself. If I don't do that I can go far longer between crashes but I do still have times when I turn on the monitor and FireFox has crashed while I've been away. Out of the last 5 crashes this one only shows once but it does appear to be the majority of my crashes overall, several of the last 5 have no information to report too. I can be doing something as simple as refreshing a web site like Engadget or scrolling using my mouse wheel to have this occur or just watching videos on Youtube or Break.com. If I could reliably repro this I would certainly post how! :-( Sometimes the browser appears to stumble, I get a busy icon and "not responding" and then it comes back - for awhile. Minutes or seconds later it dies though and were it not for session saver I'd have gone nuts long ago. One thing that does seem odd that I notice is Facebook will sometimes refuse to respond to my attempts to post comments or select links. I suspect there's Ajax or Javascript going in the background that somehow dies. This seems to occur mostly after FireFox has crashed and I've brought it back up, I think this points to my Java install but updating it hasn't helped and other sites function fine. IE at that point also functions fine <sigh>

Were it not for the bug system pointing to this bug honestly I'd blame Flash, it seems most in common to my issues.
Attached patch proposal (obsolete) — Splinter Review
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #439866 - Flags: review?(Olli.Pettay)
Comment on attachment 439866 [details] [diff] [review]
proposal

This might actually help, if the problem happens because of CC.
But don't add useless assertions. You handle the problematic case anyway.
Attachment #439866 - Flags: review?(Olli.Pettay) → review+
Attached patch less assertiveSplinter Review
Attachment #439866 - Attachment is obsolete: true
Attachment #439904 - Flags: review+
tryserver approves
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/a51c5fff6cf0
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Comment on attachment 439904 [details] [diff] [review]
less assertive

I've hit this crash on 1.9.2 a couple times and it looks like a simple fix.  Worth taking?
Attachment #439904 - Flags: approval1.9.2.5?
Comment on attachment 439904 [details] [diff] [review]
less assertive

We will not be taking this for 3.6.6. Moving approval request forward.

If you disagree, send me an email.
Attachment #439904 - Flags: approval1.9.2.7?
Attachment #439904 - Flags: approval1.9.2.6-
Attachment #439904 - Flags: approval1.9.2.5?
Comment on attachment 439904 [details] [diff] [review]
less assertive

khuey pinged me in IRC and convinced me :-)

a=LegNeato for 1.9.2.6
Attachment #439904 - Flags: approval1.9.2.7?
Attachment #439904 - Flags: approval1.9.2.6-
Attachment #439904 - Flags: approval1.9.2.6+
If I understand correctly, this bug is supposed to be fixed in Firefox 3.6.6? Well, I have a crash with this signature in 3.6.6 (build ID 20100625231939). Don't know how to reproduce it.
Crash report: bp-9afb0f25-e901-4cbc-8b93-6eedf2100629
No, this is supposed to be fixed in 3.6.7, as the flag says.
Did we identify any STR for this? It looks like there is nothing for QA to do here except watch crashstats after we ship.
Whiteboard: [qa-examined-192] [qa-needs-STR]
(In reply to comment #19)
> Did we identify any STR for this? It looks like there is nothing for QA to do
> here except watch crashstats after we ship.

Yeah I don't think there's much more you can do.
All right. Marking this as having nothing further for QA to do.
Whiteboard: [qa-examined-192] [qa-needs-STR] → [qa-ntd-192]
someone should be able to use crash-stats to verify this is resolved. we're getting plenty of reports.

i think perhaps the best case (seems to work for one of the reporters) is to have 320+ tabs (preferably with webapps which are likely to use setTimeout during their initialization) and then kill the process. By using session restore to restore your session, you're probably going to be late.

this is purely speculative, but it kinda makes some sense :)
Crash Signature: [@ nsJSScriptTimeoutHandler::SetLateness(unsigned int)]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: