Please report any other irregularities here.
328 bytes, text/plain
This bug is being used to track all misc "Crash on Exit bugs". Reported by firstname.lastname@example.org - On Win95 Build: M4 with Fullcircle Causes keyboard to stop responding. run apprunner close apprunner watch apprunner crash keyboard stops responding APPRUNNER caused an invalid page fault in module RPCRT4.DLL at 015f:7fbd1052. Registers: EAX=00000000 CS=015f EIP=7fbd1052 EFLGS=00010246 EBX=816176c4 SS=0167 ESP=015dfd8c EBP=015dfdc0 ECX=c65b35c0 DS=0167 ESI=7fbd0000 FS=2367 EDX=c00300f4 ES=0167 EDI=00000000 GS=0000 Bytes at CS:EIP: ff 70 28 ff 15 78 a0 c1 7f c7 05 ec 91 c1 7f 01 Stack dump: 00000000 00000000 7fbd0000 816176c4 7fd684cc 7fd03f2c bff741fb 015dfd90 015dfbbc 015dff78 7fbd90ce 7fc124d0 ffffffff 015dff88 bff7ddcd 7fbd0000 When I close apprunner, it closes but windows give me a message saying that it crashed with rpcrt4.dll and the apprunner's dos box is left open. If I try to close that, the dos box freezes and my keyboard does not work except for the numlock key.
First bug above is originally: http://bugzilla.mozilla.org/show_bug.cgi?id=5164
http://bugzilla.mozilla.org/show_bug.cgi?id=5896 email@example.com - reporter Build 1999050308 run apprunner wait for apprunner to load close apprunner using the [x] button This message appears: APPRUNNER caused an invalid page fault in module KERNEL32.DLL at 015f:bff7b997. Registers: EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246 EBX=00000008 SS=0167 ESP=00daff28 EBP=00daff38 ECX=7802df7a DS=0167 ESI=78034120 FS=3b97 EDX=bffc9490 ES=0167 EDI=815bd920 GS=0000 Bytes at CS:EIP: ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 78034048 78001020 78034120 061b1d70 00daff98 78002b70 0000000d 78003a07 815bd920 7800ba71 000000ff 00000001 00000000 7800bcfe 000000ff 0000002b 3 times and this is found in the dos box. Setting Back menuitem to enabled Document file:///C|/UTILITIES/MOZILLA-WIN32/BIN/res/samples/BrowserInitPage.html loaded successfully Init! Reading file... Reading file...Done adding "resource:/res/rdf/remote-flash-1.rdf" to the tree Reading file... Reading file...Done adding "resource:/res/rdf/remote-flash-2.rdf" to the tree Reading file... Reading file...Done adding "resource:/res/rdf/remote-flash-3.rdf" to the tree Reading file... Reading file...Done runtime error R6016 - not enough space for thread data runtime error R6016 - not enough space for thread data runtime error R6016 - not enough space for thread data
*** Bug 5896 has been marked as a duplicate of this bug. ***
Elevating this to a P1 blocker.
Moved from bug: http://bugzilla.mozilla.org/show_bug.cgi?id=7938 Reporter: firstname.lastname@example.org Crash on exit in AppRunner Steps: - Remove reg - run (all fine) - Change dll - run: crash (everytime) Stace Trace: #0 0x40958fac in ?? () #1 0x4067cac7 in gdk_exit () #2 0x400217df in nsAppShellService::Shutdown (this=0x807bc08) at nsAppShellService.cpp:413 #3 0x40a6139f in nsEditorAppCore::Exit (this=0x80f54d8) at nsEditorAppCore.cpp:957 #4 0x40a71204 in EditorAppCoreExit (cx=0x80f44a0, obj=0x825ae98, argc=0, argv=0x81c7bc0, rval=0xbfffe188) at nsJSEditorAppCore.cpp:1103 #5 0x40445c83 in js_Invoke (cx=0x80f44a0, argc=0, constructing=0) at jsinterp.c:650 #6 0x40456456 in js_Interpret (cx=0x80f44a0, result=0xbfffe590) at jsinterp.c:2199 #7 0x40445ce1 in js_Invoke (cx=0x80f44a0, argc=0, constructing=0) at jsinterp.c:666 #8 0x40456456 in js_Interpret (cx=0x80f44a0, result=0xbfffe9c4) at jsinterp.c:2199 #9 0x40445ce1 in js_Invoke (cx=0x80f44a0, argc=1, constructing=0) at jsinterp.c:666 #10 0x40445f98 in js_CallFunctionValue (cx=0x80f44a0, obj=0x8152118, fval=135602464, argc=1, argv=0xbfffeb48, rval=0xbfffeb4c) at jsinterp.c:735 #11 0x4041fd95 in JS_CallFunctionValue (cx=0x80f44a0, obj=0x8152118, fval=135602464, argc=1, argv=0xbfffeb48, rval=0xbfffeb4c) at jsapi.c:2554 #12 0x4039f831 in nsJSEventListener::HandleEvent (this=0x829c370, aEvent=0x82c2bb0) at nsJSEventListener.cpp:97 #13 0x40d4a296 in nsEventListenerManager::HandleEvent (this=0x829c038, aPresContext=@0x80d4da0, aEvent=0xbfffecc0, aDOMEvent=0xbfffec38, aFlags=3, aEventStatus=@0xbfffecfc) at nsEventListenerManager.cpp:569 #14 0x40b0fd62 in RDFElementImpl::HandleDOMEvent (this=0x829bae0, aPresContext=@0x80d4da0, aEvent=0xbfffecc0, aDOMEvent=0xbfffec38, aFlags=1, aEventStatus=@0xbfffecfc) at nsRDFElement.cpp:2278 #15 0x400ea22e in nsMenuItem::DoCommand (this=0x82e78d8) at nsMenuItem.cpp:404 #16 0x400e9d3d in nsMenuItem::MenuItemSelected (this=0x82e78d8, aMenuEvent=@0xbfffed40) at nsMenuItem.cpp:300 #17 0x400eb2e2 in menu_item_activate_handler (w=0x82e5728, p=0x82e78d8) at nsGtkEventHandler.cpp:505 #18 0x4064e4ad in gtk_marshal_NONE__NONE () #19 0xab15 in ?? ()
*** Bug 7938 has been marked as a duplicate of this bug. ***
With Simon's idl-ification of the editor, the stack trace has changed: #0 0x0 in ?? () #1 0x40671060 in __DTOR_END__ () #2 0x40021e06 in nsAppShellService::UnregisterTopLevelWindow (this=0x809fb08, aWindow=0x80c5670) at nsAppShellService.cpp:638 #3 0x40022869 in nsWebShellWindow::Close (this=0x80c5670) at nsWebShellWindow.cpp:386 #4 0x4002297b in nsWebShellWindow::HandleEvent (aEvent=0xbffff078) at nsWebShellWindow.cpp:434 #5 0x400ef1aa in nsWidget::DispatchEvent (this=0x80c56e0, event=0xbffff078, aStatus=@0xbffff058) at nsWidget.cpp:997 #6 0x400ef0b4 in nsWidget::DispatchWindowEvent (this=0x80c56e0, event=0xbffff078) at nsWidget.cpp:959 #7 0x400ef120 in nsWidget::DispatchStandardEvent (this=0x80c56e0, aMsg=101) at nsWidget.cpp:974 #8 0x400edd82 in nsWidget::OnDestroy (this=0x80c56e0) at nsWidget.cpp:187 #9 0x400f075e in nsWindow::Destroy (this=0x80c56e0) at nsWindow.cpp:167 #10 0x400f0833 in handle_delete_event (w=0x80cd328, e=0x80f0300, win=0x80c56e0) at nsWindow.cpp:190
This crashes seem to be primarily on Win32.
Actually, no, the only stack trace in this bug report is the crash I reported on Linux (and am still seeing), which no one seems to be seeing on windows. The fullcircle report at the beginning of this bug report may or may not be related, but without a debugger stack trace it's hard to tell. I've changed OS to ALL since this seems to be a catch-all bug for two possibly unrelated crashes on two different platforms. (But I'm leaving the PP in the summary because the crash I'm seeing does seem to be a PP issue on Linux.)
*** Bug 7526 has been marked as a duplicate of this bug. ***
Still happening -- on my very first run of apprunner (no arguments, just browser) in this morning's build, when I exited (by the windowmanager delete button -- there's nothing in any of the menus so I can't do File->Exit) I crashed in: #0 0x10 in ?? () #1 0x40974ac7 in nsCOMPtr<nsIFactory>::~nsCOMPtr (this=0x40983c08, __in_chrg=2) at nsEditorShellFactory.cpp:131 #2 0x4096c34c in __tcf_0 () at nsEditorShellFactory.cpp:131 #3 0x407f9585 in exit (status=0) at exit.c:55 #4 0x40666ac7 in gdk_exit () #5 0x400236b6 in nsAppShellService::UnregisterTopLevelWindow (this=0x8091dd8, aWindow=0x80c63e8) at nsAppShellService.cpp:631 #6 0x40024101 in nsWebShellWindow::Close (this=0x80c63e8) at nsWebShellWindow.cpp:386 #7 0x40024213 in nsWebShellWindow::HandleEvent (aEvent=0xbffff03c) at nsWebShellWindow.cpp:434 Note that I did not ever bring up the editor in this run; not clear why it was trying to delete an nsEditorShellFactory. Sounds like the list of top level windows may be confused. This may or may be the same bug.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
akkana - don said that jband checked in a fix that might take care of this. Let us know if you still see the crash with today's build.
Here is the stack trace I got when I recently crashed on Mac (adding here in cas needed later). Problem: June 07 mac build. Crash on exit. Apprunner was idol for over 2 hours just before I selected to Quit app. Talkback Incident ID #: 9701384 Trigger Type: Program Crash Trigger Reason: PowerPC unmapped memory exception Call Stack: (Signature = .__ptr_glue 781d4720) .__ptr_glue nsMacWindow::HandleMenuCommand() [nsMacWindow.cpp, line 595] nsMacMessageSink::DispatchMenuCommand() [nsMacMessageSink.cpp, line 62] nsMacMessagePump::DispatchMenuCommandToRaptor() [nsMacMessagePump.cpp, line 842] nsMacMessagePump::DoMenu() [nsMacMessagePump.cpp, line 755] nsMacMessagePump::DoMouseDown() [nsMacMessagePump.cpp, line 412] nsMacMessagePump::DispatchEvent() [nsMacMessagePump.cpp, line 307] nsMacMessagePump::DoMessagePump() [nsMacMessagePump.cpp, line 240] nsAppShell::Run() [nsAppShell.cpp, line 90] nsAppShellService::Run() [nsAppShellService.cpp, line 401] main() [nsAppRunner.cpp, line 514] .__start
Might be a good idea to check the last few comments in a bug before marking it fixed, since I had just reported that I'm still seeing the crash in this morning's build. Reopening.
Move this out to M8 ...
Is anybody still seeing this problem? Moving out to M10 for now ...
I haven't seen the Linux crashes reported here in a long time. Can't speak for the crashes on the other platforms, since they're different.
*** Bug 9818 has been marked as a duplicate of this bug. ***
Here's the data from bug #9818: "Upon exiting apprunner (for M5-M7) the program crashes, but leaves the console window open. The close command fails to close the window. From that point on, keypresses no longer work (although I think the windows key does) Upon shutdown of the computer, it just sits on the grayed out screen forever, requiring that the reset button on the computer be used." Looks like it may be a problem that's already been fixed since I'm not seeing this now on Windows 98 ...
(Follow up to 9818) Exiting apprunner in M8 still crashs on my computer. It close the GUI window, but leaves the console open, and there seems to be no way to close it. It still locks up my keyboard (though the window key works) and requires a computer reset to recover, as windows 98 will not shut down.
The crash occurs on my (Win95b, German ed.) System, too; on my system, it is easily reproducable since I just need to start apprunner, enter the Profile details and click on File/Exit, or alternatively on the X-button in the title bar. Shortly after, apprunner crashes and the console window can't be closed anymore.
Move to M11 for now ...
Move this mess to M12 ...
Apprunner Still Crash on my Win98, in M10 release. Details Same as my M7 report: I manage to capture the last line in the DOS box: XXX WARNING: Number of webshells being leaked: 5 Does this mean anything?
Build: nightly 11-1-1999 OS: Win98 Finally ( after 6 months or so!!) figured out why Mozilla crashes on exit on my machine. The cause was JRE/Java Plugin (Java Runtime Enviroment) version 1.2 Moz didn't crash on exit after I uninstalled JRE. Wondering if this bug has anything to do with bug #1483 (which is fixed) where JRE 1.2 causes crash on startup?
Move to M14.
occurred today (reproducibly) on cpratt's old PowerComputing box (MacOS 9.0) using 1999121508. 1. install comm build, no probs. 2. start up using the default mozProfile profile. 3. quit browser via eith File > Quit or cmd+Q expected: should quit gracefully. result: always get a Type 2 error; sometimes the browser windows go away, but the menubar remains (but is inaccessible). here's what i got from MacsBug (doesn't seem informative)... PowerPC access exception at C031B4FC Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0B2FCAF0 035C6780 PPC 0B2B9F74 exit+00070 stack = $02FDCCC0 #50187456 #50187456 '•*Ã¿' (between #47M and #48M) Closing log
Some information on type @ and type 3 errore on Mac. Hope it helps: TYPE 2 Errors are also related to memory use. The Mac tried to store a chunk of data in an address that couldn't hold it. TYPE 3 Errors are called an illegal instruction errors. It means the Mac tried to execute an instruction that isn't part of its standard vocabulary. The cause may be an out-of-date system extension or hard disk driver.
Move to M15.
In the 2000010308 build using Red Hat Linux 6, the app crashes on exit. cc'ing self.
Happens on Windows 98 with Win32 2000010308: MOZILLA caused an invalid page fault in module RPCRT4.DLL at 0177:7fbd1052. Registers: EAX=00000000 CS=0177 EIP=7fbd1052 EFLGS=00010246 EBX=8185c3e8 SS=017f ESP=0169fd8c EBP=0169fdc0 ECX=d1c0da60 DS=017f ESI=7fbd0000 FS=43d7 EDX=c00300f4 ES=017f EDI=00000000 GS=0000 Bytes at CS:EIP: ff 70 28 ff 15 78 a0 c1 7f c7 05 ec 91 c1 7f 01 Stack dump: 00000000 00000000 7fbd0000 8185c3e8 7fd684cc 0169fdc0 bff741fb 0169fd90 0169fbbc 0169ff78 7fbd90ce 7fc124d0 ffffffff 0169ff88 bff7ddcd 7fbd0000 The MS-DOS window shows the following: WEBSHELL- = 3 WEBSHELL- = 2 WEBSHELL- = 1 XXX WARNING: Number of webshells being leaked: 1 WEBSHELL- = 0
*** Bug 22088 has been marked as a duplicate of this bug. ***
Summary: Crash on exit bugs → [DOGFOOD] Crash on exit bugs
this still occurs (on the mac, for me at least), so am putting on dogfood radar. will attach a stack trace soon...
Mmm, well, that stack doesn't show much: PowerPC illegal instruction at FFC10000 _ReadXPRam+015CE Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 05FED944 06BC4FC0 PPC 06C71EC4 exit+00070 I do note, however that it's trying to exectute code FFC10000, which is what is usually at address 0, so it's calling something on a nil object, perhaps.
Whiteboard: This is just a tracking bug → [PDT-]This is just a tracking bug
Setting to PDT-. Since a tracking bug, do not want on PDT+ radar as a bug to fix.
added 24441 to dependency list.
Adding "crash" keyword to all known open crasher bugs.
Putting dogfood in the keyword field.
Today's linux build(2000021609m14) crashes on exit.
http://bugzilla.mozilla.org/show_bug.cgi?id=26608 is the crash on exit bug. adding to dependencies.
Seems like the latest Linux nightly builds are all fairly prone to seg faulting and crashing on exit. In fact, about 60-70% of the time when I try to quit I get either a seg fault, or failure to quit/extra webshells... don't know if this merits filing a new bug report, don't even know where exactly to put it, so I'm tacking it in as a comment here.
FYI: There's a linux hang-on-exit bug which is being worked on, 28360, PDT+. I see hangs on exit all the time. I haven't been seeing crashes on exit, though.
i rarely/erratically see a crash upon exit on linux --however, i did get a Talkback report recently --based on using opt comm bits from 2000022108: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=36&cp=5&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5705971 Trigger Type: Program Crash Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = 0x00000000 191d7e83) 0x00000000 librdf.so + 0x312f4 (0x408522f4) libplds3.so + 0x1300 (0x40138300) librdf.so + 0x3127b (0x4085227b) librdf.so + 0x313ed (0x408523ed) librdf.so + 0x3137a (0x4085237a) libbookmarks.so + 0xa764 (0x4143b764) libxpcom.so + 0x66164 (0x400fd164) libxpcom.so + 0x3adb7 (0x400d1db7) libplds3.so + 0x1300 (0x40138300) libxpcom.so + 0x3ae30 (0x400d1e30) libxpcom.so + 0x3b10f (0x400d210f) libxpcom.so + 0x3b036 (0x400d2036) libxpcom.so + 0x66232 (0x400fd232) libxpcom.so + 0x662a1 (0x400fd2a1) libxpcom.so + 0x6694d (0x400fd94d) libxpcom.so + 0x36bb7 (0x400cdbb7) mozilla-bin + 0x3275 (0x0804b275) libc.so.6 + 0x181eb (0x4021b1eb) does anyone see anything like this?
hrm. paul, which qa person should this really go to? perhaps shrir...? anyhow, here's the most recent crash-upon-exit incident i encountered on linux (using opt comm bits from 2000.2.28). they differ from my previous one above. *sigh* http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=45&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6023531 Trigger Type: Program Crash Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11) Call Stack: (Signature = nsMsgFolder::parseURI() 9733a581) nsMsgFolder::parseURI() nsMsgFolder::GetIsServer() nsImapMailFolder::GetSubFolders() nsMsgDBFolder::WriteToFolderCache() nsMsgDBFolder::WriteToFolderCache() nsMsgIncomingServer::WriteToFolderCache() nsMsgAccountManager::writeFolderCache() _hashEnumerate__FP11PLHashEntryiPv() libplds4.so + 0x1300 (0x40139300) nsHashtable::Enumerate() nsMsgAccountManager::WriteToFolderCache() nsMsgAccountManager::Shutdown() nsMsgAccountManager::~nsMsgAccountManager() nsMsgAccountManager::Release() DeleteEntry() _hashEnumerateRemove__FP11PLHashEntryiPv() libplds4.so + 0x1300 (0x40139300) nsHashtable::Reset() nsObjectHashtable::Reset() nsObjectHashtable::~nsObjectHashtable() nsServiceManagerImpl::~nsServiceManagerImpl() nsServiceManagerImpl::Release() nsServiceManager::ShutdownGlobalServiceManager() NS_ShutdownXPCOM() main() libc.so.6 + 0x181eb (0x4021d1eb)
QA Contact: sairuh → paulmac
bug 29649 is a pdt+ crash on exit bug, esther is saying it might be fixed with 3/1 builds
Move to M16 for now ...
Target Milestone: M15 → M16
spam: moving qa contact on some bugs from paulmac to email@example.com
QA Contact: paulmac → sairuh
this really doesn't belong to me... ->paw...?
Moving to M17. Can the severity on this be reduced to something less than "blocker" since they're aren't any outstanding issues with it? Thanks.
Target Milestone: M16 → M17
bumped down severity.
Severity: blocker → major
Move to M20.
Target Milestone: M17 → M20
apologies for the spam: since this is a tracking bug, it needs the meta keyword. (shoulda added it long ago. :-)
Putting on [dogfood-] radar. Meta bug.
Whiteboard: [PDT-]This is just a tracking bug → [dogfood-]This is just a tracking bug
Move this out to M30 so I don't keep bouncing on it so often. :-)
Target Milestone: M20 → M30
Nav triage team: adding 48609 to list of dependencies. Adding [nsbeta3-] so we don't keep seeing this when we query.
Depends on: 48609
Whiteboard: [dogfood-]This is just a tracking bug → [dogfood-]This is just a tracking bug [nsbeta3-]
I'm running nightly build 2000092208 on Win 95: Mozilla crashes on exit (either from the menu or the X) and talkback doesn't seem to catch it. Here are the errors I get: MOZILLA caused an invalid page fault in module RPCRT4.DLL at 016f:7fcc15de. Registers: EAX=00000000 CS=016f EIP=7fcc15de EFLGS=00010246 EBX=00000000 SS=0177 ESP=0068fd94 EBP=0068fdbc ECX=c11885d0 DS=0177 ESI=81650388 FS=29e7 EDX=c001939c ES=0177 EDI=7fcc0000 GS=0000 Bytes at CS:EIP: ff 70 60 ff 15 e0 e0 ce 7f e9 d1 fe ff ff b8 01 Stack dump: 00000000 7fcc0000 81650388 00000000 0068fd98 0068fbc4 0068ff78 7fcc8ed2 7fceb230 ffffffff 0068ff88 bff7c00d 7fcc0000 00000002 00000000 7fcc0000 Then I click close and another dialog pops up: Microsoft Visual C++ Runtime Library Runtime Error! Program: C:\path_to_mozilla\mozilla.exe R6016 - not enough space for thread data Then another crash dialog after that one: MOZILLA caused an invalid page fault in module KERNEL32.DLL at 016f:bff79fa4. Registers: EAX=00000000 CS=016f EIP=bff79fa4 EFLGS=00000246 EBX=8162e884 SS=0177 ESP=0068ff24 EBP=0068ff34 ECX=800051a0 DS=0177 ESI=780423f0 FS=29e7 EDX=80005220 ES=0177 EDI=0000000d GS=0000 Bytes at CS:EIP: ff 76 04 e8 3d a2 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 02685f50 78001131 780423f0 81650344 0068ff98 78002f50 0000000d 78005228 02685f50 0068ff98 8162e884 780173f9 000000ff 00000001 00000000 780176b5 I don't have to load any particular page before this happens.
djk's add is a dupe of bug #53353
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Status: REOPENED → NEW
Is this still an alive bug? Can I close it as fixed? thanks, Vishy
Sarah, can you answer Vishey question. Thanks Updating QA contact
QA Contact: paw → sairuh
hrm, this is just a tracking bug... not sure if resolving it is worthwhile. i'd prefer to keep it open, in order to continue tracking crash-on-quit bugs...
This bug doesn't look like it's tracking anything right now, and it's showing up on all kinds of radars. Recommend that we mark this as fixed and open another bug as needed. Over to pchen.
Assignee: vishy → pchen
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 18 years ago
Resolution: --- → WORKSFORME
sairuh agrees to mark this WFM. This bug is currently not tracking anything, we should create a new tracking bug if we need to track this stuff again.
mass verification of WorksForMe bugs: to find all bugspam pertaining to this, set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM". if you think this particular bug is *still* an open issue, please make sure of the following before reopening: a. that it's still a problem with ***recent trunk builds*** on the all appropriate platform[s] b. provide clear steps to reproduce (unless a good test case is already in the bug report), making sure it pertains to the original problem (avoid morphing as much as possible :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.