Closed Bug 149109 Opened 23 years ago Closed 22 years ago

Trunk crash closing Mozilla [@ 0xffffff4d - js_GC]

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jay, Assigned: bugs)

References

(
URL
)

Details

(4 keywords)

Crash Data

Attachments

(2 files)

Recent 0xffffff4d crashes on MozillaTrunk
31.10 KB, text/plain
Details
Brian's stack
1.45 KB, text/plain
Details
This crash started with MozillaTrunk builds on 5/28. Users crash closing their Mozilla windows or exiting Mozilla all together. Not sure I picked the right component, so please update and reassign as needed. Here are a couple sets of crashes reported by Talkback: Count Offset Real Signature [ 3 0xffffff4d 7c2451f7 - js_GC ] [ 2 0xffffff4d 9689b559 - js_GC ] [ 2 0xffffff4d 05a0fdd5 - js_GC ] [ 1 0xffffff4d fec37f44 - js_GC ] [ 1 0xffffff4d dc5ecf85 - js_GC ] Crash date range: 2002-05-30 to 2002-06-01 Min/Max Seconds since last crash: 6 - 31710 Min/Max Runtime: 151 - 69391 Keyword List : Count Platform List 9 Windows NT 5.1 build 2600 Count Build Id List 5 2002053104 2 2002053008 2 2002052908 No of Unique Users 4 Stack trace(Frame) 0xffffff4d 0x00bb1008 js_GC [jsgc.c line 1263] js_ForceGC [jsgc.c line 981] js_DestroyContext [jscntxt.c line 243] nsJSContext::~nsJSContext [nsJSEnvironment.cpp line 468] nsJSContext::`scalar deleting destructor' nsJSContext::Release [nsJSEnvironment.cpp line 500] nsCOMPtr_base::assign_with_AddRef [nsCOMPtr.cpp line 74] nsXULPrototypeDocument::~nsXULPrototypeDocument [nsXULPrototypeDocument.cpp line 247] nsXULPrototypeDocument::Release [nsXULPrototypeDocument.cpp line 257] nsSupportsHashtable::ReleaseElement [nsHashtable.cpp line 939] _hashEnumerate [nsHashtable.cpp line 200] PL_HashTableEnumerateEntries [plhash.c line 430] nsHashtable::Enumerate [nsHashtable.cpp line 363] nsSupportsHashtable::~nsSupportsHashtable [nsHashtable.cpp line 945] nsXULPrototypeCache::~nsXULPrototypeCache [nsXULPrototypeCache.cpp line 211] nsXULPrototypeCache::`scalar deleting destructor' nsXULPrototypeCache::Release [nsXULPrototypeCache.cpp line 211] nsXULPrototypeScript::ReleaseGlobals [./../xul/content/src\nsXULElement.h line 339] Shutdown [nsContentModule.cpp line 257] nsGenericModule::Shutdown [nsGenericFactory.cpp line 325] nsThreadPool::Release [nsThread.cpp line 502] nsDll::Shutdown [xcDll.cpp line 478] nsFreeLibrary [nsNativeComponentLoader.cpp line 386] nsFreeLibraryEnum [nsNativeComponentLoader.cpp line 435] _hashEnumerate [nsHashtable.cpp line 200] PL_HashTableEnumerateEntries [plhash.c line 430] nsHashtable::Enumerate [nsHashtable.cpp line 363] nsNativeComponentLoader::UnloadAll [nsNativeComponentLoader.cpp line 1016] nsComponentManagerImpl::UnloadLibraries [nsComponentManager.cpp line 3023] nsComponentManagerImpl::Shutdown [nsComponentManager.cpp line 824] NS_ShutdownXPCOM [nsXPComInit.cpp line 585] main [nsAppRunner.cpp line 1816] WinMain [nsAppRunner.cpp line 1826] WinMainCRTStartup() kernel32.dll + 0x1eb69 (0x77e3eb69) ------------------------------------------------------------------------------ Count Offset Real Signature [ 2 0xffffff4d d8a5e4a3 - js_GC ] [ 2 0xffffff4d 556504a4 - js_GC ] Crash date range: 2002-05-29 to 2002-06-01 Min/Max Seconds since last crash: 3 - 5930 Min/Max Runtime: 511 - 6677 Keyword List : Count Platform List 2 Windows NT 5.0 build 2195 2 Windows 98 4.10 build 67766446 Count Build Id List 2 2002053104 2 2002052908 No of Unique Users 2 Stack trace(Frame) 0xffffff4d 0x00dc2008 js_GC [jsgc.c line 1263] js_ForceGC [jsgc.c line 981] js_DestroyContext [jscntxt.c line 243] nsJSContext::~nsJSContext [nsJSEnvironment.cpp line 468] nsJSContext::`scalar deleting destructor' nsJSContext::Release [nsJSEnvironment.cpp line 500] nsCOMPtr_base::assign_with_AddRef [nsCOMPtr.cpp line 74] nsXULPrototypeDocument::~nsXULPrototypeDocument [nsXULPrototypeDocument.cpp line 247] nsXULPrototypeDocument::Release [nsXULPrototypeDocument.cpp line 257] nsSupportsHashtable::ReleaseElement [nsHashtable.cpp line 939] _hashEnumerate [nsHashtable.cpp line 200] PL_HashTableEnumerateEntries [plhash.c line 430] nsHashtable::Enumerate [nsHashtable.cpp line 363] nsSupportsHashtable::~nsSupportsHashtable [nsHashtable.cpp line 943] nsSupportsHashtable::~nsSupportsHashtable [nsHashtable.cpp line 945] nsXULPrototypeCache::`scalar deleting destructor' nsXULPrototypeCache::Release [nsXULPrototypeCache.cpp line 211] nsXULPrototypeScript::ReleaseGlobals [./../xul/content/src\nsXULElement.h line 339] Shutdown [nsContentModule.cpp line 257] nsGenericModule::Shutdown [nsGenericFactory.cpp line 325] nsThreadPool::Release [nsThread.cpp line 502] nsDll::Shutdown [xcDll.cpp line 478] nsFreeLibrary [nsNativeComponentLoader.cpp line 386] nsSupportsHashtable::~nsSupportsHashtable [nsHashtable.cpp line 945] nsXULPrototypeCache::~nsXULPrototypeCache [nsXULPrototypeCache.cpp line 211] nsXULPrototypeCache::`scalar deleting destructor' nsXULPrototypeCache::Release [nsXULPrototypeCache.cpp line 211] nsXULPrototypeScript::ReleaseGlobals [./../xul/content/src\nsXULElement.h line 339] Shutdown [nsContentModule.cpp line 257] nsGenericModule::Shutdown [nsGenericFactory.cpp line 325] nsThreadPool::Release [nsThread.cpp line 502] nsDll::Shutdown [xcDll.cpp line 478] nsFreeLibrary [nsNativeComponentLoader.cpp line 386] nsFreeLibraryEnum [nsNativeComponentLoader.cpp line 435] _hashEnumerate [nsHashtable.cpp line 200] PL_HashTableEnumerateEntries [plhash.c line 430] nsHashtable::Enumerate [nsHashtable.cpp line 363] nsNativeComponentLoader::UnloadAll [nsNativeComponentLoader.cpp line 1016] nsComponentManagerImpl::UnloadLibraries [nsComponentManager.cpp line 3023] nsComponentManagerImpl::Shutdown [nsComponentManager.cpp line 824] NS_ShutdownXPCOM [nsXPComInit.cpp line 585] main [nsAppRunner.cpp line 1816] WinMain [nsAppRunner.cpp line 1826] WinMainCRTStartup() KERNEL32.DLL + 0xd326 (0x77e8d326) (6893231) Comments: I closed a Mozilla window. (6877314) Comments: I closed a Mozilla window. (6816493) URL: http://www.adventeurope.com/ (6816493) Comments: closing mozilla causes crash (6816492) URL: http://www.adventeurope.com/ (6816492) Comments: closing mozilla causes it to crash I haven't been able to reproduce this, but it's definitely some sort of regression. Does anyone know of a checkin that went in on 5/28 that would have caused this?
Adding crash, topcrash and regression keywords. Also adding qawanted to see if anyone can reproduce this.
Keywords: crash, qawanted, regression, topcrash
Hyatt's on sabbatical, don't give him topcrash bugs. What changes went in for 5/28 builds that might be to blame? Cc'ing dbaron and jrgm, reassigning to Ben in case this dups something he knows about. /be
Assignee: hyatt → ben
5/28 was a rather uninteresting day, karnaze landed something, but it doesn't look like it fits. 5/23 dbaron played with quirks mode which slightly touched xuldocument over 5/23..5/27 cavin and i made a mess of wallet do you see this on Mac or Linux? if not, my best guess is: kyle.yuan%sun.com mozilla/accessible/src/xul/nsXULFormControlAccessible.cpp But this is all straw grasping. (and that file is technically XP) Blake also added some observer service code to the download manager (js) but...
WFM with build 2002052306 under Windows ME.
mozilla/accessible/src/xul/nsXULFormControlAccessible.cpp is in accessibility.dll, which doesn't even get loaded unless a screen reader or Immersion Touchware is present.
Talkback data says this is only on Windows...mostly WinXP, but there are incidents for Win 98, NT and 2k as well. Looking at this query: http://climate.mcom.com/reports/VeryFastSearchStackSigNEW.cfm?stacksig=0xffffff4d It looks like a couple users are crashing quite a lot...so it might be some sort of system config or profile issue, but that's just a guess.
Because this arrived "suddenly" in builds of 05/28, I'm a little skeptical that this is, at least directly, due to XUL Fastload. Yes, there is some XULPrototype code in the teardown stack, but XUL Fastload landed on the trunk in early May and (mostly) hasn't changed. I looked at the checkins for 05/27->05/28 and they looked so "guiltless" that I checked the mozilla ftp server. I noticed the last win32 build that was pushed before 05/28 was 2002-05-25-08-trunk (aside from an SVG win32 build at 2002-05-27-08-trunk). So, that's a wider window (Memorial Day weekend). This comment by dbaron in bug 145737 seems a tiny bit suspect, given that this crash is on shutdown: "It's a little bit of a hack ... since it's only clearing the undisplayed map a little earlier in the shutdown process. Scripts won't run after this point, so we don't really need to worry about dynamic style changes..." Otherwise, my other two possibles (just because they are in JS) are khanson for [no bug number :-/] rev 3.36 or jsarray.c and brendan for bug 146596. But perhaps it's something. Please review the checkin list.
URL: http://www.adventeurope.com/ → 2Fcvsroothttp://bonsai.mozilla.org/cv...
The missing bug number (for rev 3.36 of jsarray.c) in comment #7 is 143354. khanson
Bug 145737 wouldn't cause crashes if scripts continued to run after when I thought they do -- only correctness problems, like the correctness problems caused by the fix for bug 118014 that's been on the 1.0 branch for ages.
Just for the record, this crash has not shown up in MozillaTrunk Talkback data since 6/4. Something either fixed this, the crash has magically disappeared...or no one has been able to reproduce this lately. Whatever the case may be, I'm going to mark this worksforme. Please reopen if anyone is able to reproduce a crash with this stack signature and trace.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reopening. This crash popped up again as a topcrasher starting with MozillaTrunk builds on 7/12. There have been a good number of crashes each data since then with user quitting mozilla.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
There are a couple of different looking stacks, but I'm guessing they are all related since all the user comments mention quitting Mozilla. I have attached all the recent crashes reported through Talkback.
Not sure how to go about looking for what might have introduce this crash, but here is a list of checkins between 7/11 00:00 and 7/12 05:00 (maybe someone else can find a change that might have caused this): http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F11%2F2002+00%3A00%3A00&maxdate=07%2F12%2F2002+04%3A59%3A59&cvsroot=%2Fcvsroot
The reporter of bug 159652 has a couple of stacks that terminate with the identical last 4-5 frames. His issue was that he had installed M1.1 Beta over M1.1 Alpha. If that is the case with this bug it might explain why it disappeared and them reappeared for no reason directly connected to checkins. I would hypothesize that it shows up around release dates. Users download the new release, install it over the previous release and start generating crashes. Note: this bug was reopened on 6-13. M1.1 Alpha was released two days earlier.
I have 3 builds installed each one using a different profile (mozilla 1.0.1 nightly, mozilla 1.1 beta, mozilla trunk nightly) I can see this bug only when I'm running 1.1 beta (the crash occurs almost everytime I close mozilla) . This does not happen with the 2 other builds I use.
Well, Talkback data supports Bernard's test results. After seeing a huge spike in these crashes on the Trunk between 7/12 - 7/23 (A LOT of crashes with builds from 7/21 and 7/22 b/c of Mozilla 1.1 Beta), there have been 0 crashes since with MozillaTrunk builds (this was never an issue with Gecko 1.0 Branch builds). Not sure what might have fixed this crash. If anyone knows a checkin on 7/23 that would have fixed this please note it here and mark it fixed. Otherwise we'll just have to mark this worksforme and hope it doesn't pop up again.
I'm the reporter of bug 159652 that greer mentioned in comment 15. I just wanted to mention that despite following his advice and reinstalling 1.1beta 'clean' (instead of over 1.1alpha), I am still experiencing crashes on every exit. e.g. TB8905870Q.
Attached file Brian's stack —
Brian's stack for the record to verify it's the same stack.
No sign of this bug under Mac OS. WFM under Mac OS 9.2.2, Mozilla trunk build 2002103008. Seems to be a Win 2K bug.
base on the last 5 comments, this looks like it's worth marking worksforme. if anyone sees this crash again, please feel free to reopen. thanks.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
I got this crash today in my build on win2k. I opened a link to cls blog from a Newsgroup and Mozilla crashed after i closed the window. fffff4d() 00e8a008() js_GC(JSContext * 0x058529d8, unsigned int 0x00000000) line 1298 js_ForceGC(JSContext * 0x058529d8, unsigned int 0x00000000) line 995 + 25 bytes js_DestroyContext(JSContext * 0x00ff24d8, int 0x058529d8) line 242 + 8 bytes nsXPConnect::ReleaseJSContext(nsXPConnect * const 0x060da800, JSContext * 0x01e9353e, int 0x00000001) line 1081 nsJSContext::`scalar deleting destructor'(nsJSContext * const 0x0573cfd0, unsigned int 0x060da800) + 8 bytes nsTimerImpl::`scalar deleting destructor'(nsTimerImpl * const 0x0573cfd0, unsigned int 0x060da800) + 8 bytes nsTimerManager::FireNextIdleTimer(nsTimerManager * const 0x00f195e8) line 616 + 6 bytes nsAppShell::Run(nsAppShell * const 0x00f195e8) line 142 nsAppShellService::Run(nsAppShellService * const 0x00f0ba78) line 478 main1(int 0x00000000, char * * 0x00243de8, nsISupports * 0x00000000) line 1290 + 9 bytes main(int 0x00000003, char * * 0x00243de8) line 1669 + 22 bytes WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x001334ee, HINSTANCE__ * 0x00400000) line 1693 + 23 bytes MOZILLA! WinMainCRTStartup + 308 bytes KERNEL32! 77e787f5()
Matti, what revisions of jsgc.c and jsscript.c did you use in your build? /be
Brendan : File: jsgc.c, Status: Up-to-date, Working revision: 3.78 File: jsscript.c, Status: Needs Patch,Working revision: 3.41 (my build is without the patch from bug 214210, could this be the cause ?)
Yes, that's it. You need to update and rebuild, I think. Leaving this bug RESOLVED WORKSFORME. /be
I just crashed today with Firefox trunk build with a similar stack signature, sorry if I've interpreted the talkback result wrong (talkback: TB3104307Y). Is it the same thing? It occured when I closed Firefox. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050115 Firefox/1.0+
Tablet: file a new bug, citing the talkback incident ID if one was generated. This bug is old and should not be reused for anything new that happens to crash in the GC. /be
Crashes with this signature have gained new life as bug 314484. Currently 30% of the Firefox 1.5rc1 crashes
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
Crash Signature: [@ 0xffffff4d - js_GC]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: