Closed Bug 314484 Opened 18 years ago Closed 18 years ago

Firefox 1.5 RC1 topcrash [@ 0xffffff4d] [@ js_GC]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

(
URL
)

Details

(4 keywords, Whiteboard: Bug tickled by Greasemonkey?)

Crash Data

We're seeing a lot of crashes [@ 0xffffff4d]:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=0xffffff4d&vendor=MozillaOrg&product=Firefox15&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Most of the stacks are:

0xffffff4d <-- this number does not vary
0x010f2008 <-- this number varies but always starts with 0x01
js_GC
js_ForceGC
nsAppStartup::Run
main
kernel32.dll + 0x16d4f (0x7c816d4f)

Some stacks stop at js_ForceGC (so they're only four lines long).

All of these crashes are on Windows.

The comments vary and don't mention to a way to reproduce the crash.

According to http://talkback-public.mozilla.org/reports/firefox/, crashes with 0xffffff4d at the top make up 12.8% of crashes on the Firefox 1.5 branch.  It's probably more like 20% of the user-facing crashes because a lot of the other crash reports are from automatic testing on bclary's machines.

Thunderbird 1.5 RC1 suffers too but not as much (2 crashes = 3% of crashes, TB11224898 and TB11208907).

According to Talkback, the crashes started appearing in 2005-10-24-00.
Flags: blocking1.8rc1?
Talkback TB11194296 offer a longer stack of the same problem (which don't seems to be related to closing Firefox):

user expanation: double clicking really fast randomly in the page (	http://www.eweek.com)

0xffffff4d
0x01081008
js_GC
js_ForceGC
js_Interpret
js_Invoke
nsXPCWrappedJSClass::CallMethod
nsXPCWrappedJS::CallMethod
SharedStub
nsEventListenerManager::HandleEventSubType
nsEventListenerManager::HandleEvent
nsGenericElement::HandleDOMEvent
PresShell::HandleEventInternal
PresShell::HandleEventWithTarget
nsEventStateManager::CheckForAndDispatchClick
nsEventStateManager::PostHandleEvent
PresShell::HandleEventInternal
PresShell::HandleEvent
nsViewManager::HandleEvent
nsViewManager::DispatchEvent
HandleEvent
nsWindow::DispatchEvent
nsWindow::DispatchMouseEvent
ChildWindow::DispatchMouseEvent
nsWindow::WindowProc
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run
nsAppStartup::Run
main
kernel32.dll + 0x16d4f (0x7c816d4f)
Confirmed I have this for a week now. reported it many times but did not open a new bug. This should be a blocker .. for RC2.
Flags: blocking1.8rc2?
A lot of people (on the forum) complain about the semi random crashes

Incident ID: 11256070
Stack Signature	0xffffff4d 47c37193
Product ID	Firefox15
Build ID	2005103002
Trigger Time	2005-10-30 11:03:18.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	Crashed without an apparent cause (didn't click anywhere or do anything, like a time-bomb). On the last few days I am getting crashes regularly but not predictably. Both on my office system and home (both FF1.5RC). It could be an extension, but then again
Since Last Crash	477 sec
Total Uptime	477 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0xffffff4d
0x01100008
js3250.dll + 0x1da24 (0x6009da24)
js3250.dll + 0x1d4b5 (0x6009d4b5)
firefox.exe + 0x3fc7c3 (0x007fc7c3)
firefox.exe + 0x1012 (0x00401012)
kernel32.dll + 0x16d4f (0x7c816d4f)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This may be related to Greasemonkey, I'm using v0.6.2
Haven't seen a crash today, since I disable it.
I've been using the Windows Nightly Branch builds for months, currently on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051031 Firefox/1.5 ID:2005103103, along with Greasemonkey, and have never come across this. I've been using Greasemonkey 0.6.3 for about 2 weeks with no issue. 

dimitrisp, you may want to give 0.6.3 a try and see if it still crashes. You can grab it here:

http://mozdev.org/pipermail/greasemonkey/attachments/20051016/d90681bf/greasemonkey-0.6.3-0001.bin
Tim, just installed 0.6.3 and got a crash within the first minute (with no crash while it was disabled all day)

I'm using the "Linkify plus" and "Slashdot - comment tree" scripts.
I can attach them here if that'd be helpful
Sounds like greasemonkey is causing this.
Whiteboard: Caused by Greasemonkey?
(In reply to comment #7)
> Sounds like greasemonkey is causing this.

Not according to comment 6.

Also, GM is all JS, so the bug is in our code, and any extension could tickle it. Others probably are (not that GM by itself isn't major enough ;-).

/be
Whiteboard: Caused by Greasemonkey? → Bug tickled by Greasemonkey?
I am not a GM user, yet at least one of the crashes in the link from comment 0 is one of mine, so we can be confident that this is not a GM-only crasher.
(In reply to comment #9)
> I am not a GM user, yet at least one of the crashes in the link from comment 0
> is one of mine, so we can be confident that this is not a GM-only crasher.
> 

that's what i was wondering to. Because I can crash with only a download task in the tab bar. I just lost the file I was d/l minutes ago, re d/l with trunk it's more stable .. heh
Brendan:  I found a few incidents with line numbers, most of them were consistent at js_GC line 1817.  Here is one with a recent build:

Incident ID: 11296901
Stack Signature	0xffffff4d fda1c5e9
Product ID	Firefox15
Build ID	2005102603
Trigger Time	2005-10-31 12:26:17.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	
URL visited	
User Comments	Nothing, although there was a frame open with an auto-refresh, so that may have triggered the crash.
Since Last Crash	7570 sec
Total Uptime	56017 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0xffffff4d
0x01620008
js_GC  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1817]
js_ForceGC  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1510]
nsAppStartup::Run  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 151]
main  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61]
KERNEL32.dll + 0x28989 (0x7c598989)
Flags: blocking1.8rc1?
Jay Patel and I tried to get the x86 registers for some of the Talkback reports from the internal Talkback server, but we weren't able to.
(In reply to comment #12)
> Jay Patel and I tried to get the x86 registers for some of the Talkback reports
> from the internal Talkback server, but we weren't able to.
> 

All my talkback id's are deleted from my MQFA each times I update since this crash appeared ... There was server-side issues the past few days but I doubt it can cause my incidents id to be deleted and the agent is turning off. I have to enable it back again.
If someone can give me a way to reproduce this, we will add it to the test library.
Flags: testcase-
(In reply to comment #14)
> If someone can give me a way to reproduce this, we will add it to the test
> library.
> 

like we said, it's happening randomly. See, I opened firefox and let it on my homepage for like 15 min while I was elsewhere. Came back, came on mozillazine forum and ... eureca ! .. I mean crash ! @ 0xffffff4d 

And by the way, talkback is always down now this is not helping us for sure. Just installed RC1 on my little brothers fresh installed pc and I said to him to report any crashes to me.
(In reply to comment #8)
> (In reply to comment #7)
> > Sounds like greasemonkey is causing this.
> 
> Not according to comment 6.
> 

Somehow I think you are misreading comment number 6.  The reporter said it crashed  within a minute after installing [Greasemonkey] 0.6.3 and that Greasemonkey was subsequently disabled and Firefox then ran a full day without a crash.
(In reply to comment #16)
> 
> Somehow I think you are misreading comment number 6.

You are right -- but what about comment 9 and comment 10?  Anyway, a platform bug tickled by GM will be easier to track down, even if other extensions tickle it too.  Does anyone have more hints on how to reproduce?  What user scripts, if any, were in use?

/be
As expected, this is the #1 topcrasher with RC1 (at about 30% of all crashes coming in): http://talkback-public.mozilla.org/reports/firefox/FF15rc1/FF15rc1-topcrashers.html

I have not been able to find any register info for this crash, and have not been able to reproduce.  If we can somehow reproduce this on Linux, we can get the register info...and if not, at least a consistent set of steps to reproduce this can help us debug.

Adding topcrash+ and helpwanted keywords.  This should block RC2.
Keywords: topcrash → helpwanted, topcrash+
http://www.arantius.com/misc/greasemonkey/linkify-plus.user.js
http://userscripts.org/scripts/source/1830.user.js

These are the scripts I'm using with Greasmonkey 0.6.2 and 0.6.3 when crashes occur.

The crashes happen unpredictably, it may take 1 minute, or half an our. I usually have 3 to 5 tabs open.

I'm running with Greasmonkey disabled for a few days now and haven't had a single crash.
For those trying to reproduce this, check out: http://talkback-public.mozilla.org/reports/firefox/FF15rc1/smart-analysis.all

That topcrash report has a lot of comments and urls under the 0xffffff4d section.  Hopefully someone will be able to use that data to find a way to crash.
just wanna add here that I have not been able to crash since 20051101 build. So I assume that one of the check-in we got fixed that problem ? Can somebody confirm ?
Talkback only shows one of these crashes for Nov 1 and none for subsequent builds.  Marking WFM.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking1.8rc2?
Resolution: --- → WORKSFORME
*** Bug 305701 has been marked as a duplicate of this bug. ***
(In reply to comment #22)
> Talkback only shows one of these crashes for Nov 1 and none for subsequent
> builds.  Marking WFM.
> 

confirming WFM

one of the check-ins the day after RC1 release fixed this crash it seems.
marking as a blocker so that this doesn't get lossed when we go to verify things.
Flags: blocking1.8rc2+
I don't use greasemonkey, but current Session Saver extension seems to be equally efficient to kill modern nightly build of Firefox. See my comment in  http://forums.mozillazine.org/viewtopic.php?t=47184&postdays=0&postorder=asc&postsperpage=15&start=1665&sid=2c61975c96dc7b4bc30b28d88e191122

Last comments in this bug seem to indicate that latest builds don't crash. I just update to Firefox 2005110704 build. Let's see :-)
(In reply to comment #26)
> I don't use greasemonkey, but current Session Saver extension seems to be
> equally efficient to kill modern nightly build of Firefox. See my comment in 
> http://forums.mozillazine.org/viewtopic.php?t=47184&postdays=0&postorder=asc&postsperpage=15&start=1665&sid=2c61975c96dc7b4bc30b28d88e191122
> 
> Last comments in this bug seem to indicate that latest builds don't crash. I
> just update to Firefox 2005110704 build. Let's see :-)

This bug is marked WFM based on 1 Nov 2005 and newer builds showing no recurrence of the problem.  See comment 22.

If you are testing a build from October, you need to upgrade.  In any event, you should provide talkback ids.

/be
Current Firefox nightly builds seems much more stable. Good. Previously I had crashes every 1-2 hours.

But I've haven two firefox crashes in 48 hours. No talkbacks, nevertheless. I've just activate the talkback service. Seems not automatically activated after upgrading.

And Thunderbird, rock solid until now, is crashing too. Three crashes in 48 hours. Current nightly builds. Talkback service just activated.

Let's see.

Sorry for the spam.

I'm still having Firefox crashes (every 24 hours) and thunderbird crashes (2-3 times per day). Current nightly builds.

I have talkback enabled in both programs, but the crashes seem not be catched. Is talkback enabled only in RC/Final builds?. It is done on purpose (to decrease noise from buggy nightly builds) or must I file a bug?.

How can I help to debug this?. How can I enable talkbacks?. Any idea?

Thanks for your time and attention.

PS: Linux OS here, BTW

(In reply to comment #29)
> How can I help to debug this?. How can I enable talkbacks?. Any idea?

You need to file a new bug based on new data.  Try the mozillazine.org forums for help on getting talkback working.  What you are seeing is not likely to be the crash this bug reports, and it deserves a new bug report.

/be
Sounds like this has reappeared as bug 347053.
Crash Signature: [@ 0xffffff4d] [@ js_GC]
You need to log in before you can comment on or make changes to this bug.