Closed Bug 314484 Opened 15 years ago Closed 15 years ago
.5 RC1 topcrash [@ 0xffffff4d] [@ js _GC]
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.
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.
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)
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.
(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.
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: 15 years ago
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.
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.