Closed Bug 130234 Opened 18 years ago Closed 18 years ago
.9 .9 crashes at startup on w95
No one seems to have reported this yet but I can't believe I'm the only one experiencing this problem. After installing the 0.9.9 release build for Windows (tried both stub and full install downloads), Mozilla crashes on startup after the profile manager dialog with the following error: This program has performed an illegal operation and will be shut down. .... Details: MOZILLA caused an invalid page fault in module APPCOMPS.DLL at 0137:60078146. Registers: EAX=00000000 CS=0137 EIP=60078146 EFLGS=00010246 EBX=00000000 SS=013f ESP=0064efa8 EBP=0064f150 ECX=0064f13c DS=013f ESI=00000000 FS=0f7f EDX=0064f13c ES=013f EDI=80000000 GS=0000 Bytes at CS:EIP: 8b 08 ff 91 bc 00 00 00 8b f8 be 00 00 00 80 85 Stack dump: 00000000 0064f13c 80000000 00000000 01f926d8 027589f0 0064efe4 60f1816a 027589f4 610ebfe3 027589f4 610ca8f0 027589f0 027589f0 0064f080 0064f028 There is more debug information in the talkback reports I have submitted. Mozilla crashes on subsequent invocations as well never fully rendering the browser window. I'm am running Win 95B (hey it works why use anything newer and more bloated) on a Pentium with 64MB memory and over 100MB free disk space. These are the following things I have tried to rule out anything else: 1. Uninstalled from add/remove programs 1. Removed the complete Mozilla program directory. 2. Removed the mozver.dat and registry.dat files left over from the uninstall. 3. Created a new empty profile. 4. Ran regclean to clean up any cruft left in the registry. I don't think it's a system problem since 0.9.8 worked fine. I'm back to using 0.9.8 until this is fixed.
Well, I'm typing this in 0.9.9, so needless to say WFM in Win98.
Darrel, could you provide talkback IDs of your crash?
I have run into this trying to install/run the latest nightly build under Win98. Haven't encountered it with the 0.9.9 release though.
I have the same problem with yesterday';s nightly build 0.9.8.2002031109. See talkback ID: TB3936739W for additional info.
I am seeing this too with the 20020312 build on Windows 95 Talkbacks TB3956546E and TB3956514Y
nsWindowMediator::Assert [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp, line 1058] RDFContainerUtilsImpl::MakeContainer [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFContainerUtils.cpp, line 462] RDFContainerUtilsImpl::MakeSeq [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFContainerUtils.cpp, line 349] nsWindowMediator::Init [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp, line 913] nsWindowMediator::nsWindowMediator [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWindowMediator.cpp, line 201] nsWindowMediatorConstructor [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellFactory.cpp, line 70] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 78] nsComponentManagerImpl::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1801] nsComponentManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1975] nsGetServiceByCID::operator() [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 215] nsCOMPtr_base::assign_from_helper [d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 81] nsAppShellService::Initialize [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 180] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1289] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1701] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1719] WinMainCRTStartup() KERNEL32.DLL + 0x18f75 (0xbff88f75) KERNEL32.DLL + 0x18e23 (0xbff88e23) KERNEL32.DLL + 0x1783f (0xbff8783f)
This sounds like a windows 95 blocker ! -> Embedding APIs
Summary: Release build 0.9.9 crashes during startup on Win 95 in APPCOMPS.DLL → 0.9.9 crashes at startup on w95 in APPCOMPS.DLL [@nsWindowMediator::Assert]
Just like to submit another confirmation of this bug on 98lite (Windows 98 with IE "removed"). Not present on 0.9.8, but present on 0.9.9 and the 3/13 and 3/14 nightly builds. Same symptoms and problems, running on a K6-200 with 128MB RAM. Possibly a dependancy on some IE component not present in non-IE Windows machines?
I thought I'd take a closer look at this but when I installed 0.9.9 again this time it worked. Also worked fine with the lastest build 2002031303. Unfortunately I've done so many things to my system in the last couple of days it's impossible for me to know what fixed the problem. If I get a chance tomorrow...err later today, I'll try and recreate the environment that led to the problem. Has anyone else noticed this problem go away for themselves as well?
I don't believe this is anything to do with embedding. nsWindowMediator::Assert(...) immediately calls mInner->Assert(...), therefore the most likely reason for the crash is mInner being NULL. mInner is created in nsWindowMediator::Init(). The most likely reason I can think for this crash is if Mozilla was installed over an old copy. It's possible in this situation that the component.reg file was not rebuilt and as a result it was unable to create the mInner object from its CLSID. If the crash is reproducable, try deleting component.reg and see if this resolves the issue. Reassigning to RDF. CC'ing myself and Robert John Churchill who has being doing work in this file recently.
Component: Embedding: APIs → RDF
Assignee: adamlock → waterson
QA Contact: mdunn → tever
I *always* delete my old build before installing a new one, but just to be sure I deleted my component.reg and tried again. No luck. Still crashing with a 20020314 build, Win95 Talkbacks TB4041695E and TB4039115K
I was unable to come up with anything definite as to why this is no longer a problem on my system. As for the component.reg. I don't think this was the problem for me, since this file would have been deleted and recreated when I completely removed the Mozilla directory from the Program Files directory on the list of things I tried. One scenario, that I cannot test, is that it is related to some sort of corruption I had in the registry. One that is not fixed by simply running Regclean. I have spent some time trying to fix, what I thought was an unrelated problem, with a corrupt windows file association. I ran several registry cleaning utilities and did some manual manipulation using Regedit which fixed the problem. Perhaps this also fixed this bug as well, maybe as a sideaffect. Or perhaps it has nothing to do with it, but this is the only light I can shed on the situation. I hope something that I have documented regarding this bug actually helps and doesn't just amount to useless drivel. Good luck to everyone else still getting this bug and to the developers trying to track it down.
I just tried running Mozilla through the Dependency Walker. Here are the last few lines of logged output before it died DllMain(0x606C0000, DLL_PROCESS_ATTACH, 0x00000000) in "LWBRK.DLL" called. DllMain(0x606C0000, DLL_PROCESS_ATTACH, 0x00000000) in "LWBRK.DLL" returned 1 (0x1). LoadLibraryA("G:\MOZILLA\BIN\components\lwbrk.dll") returned 0x606C0000. GetProcAddress(0x606C0000 [LWBRK.DLL], "NODL_TABLE") called from "NSPR4.DLL" at address 0x60EC7626 and returned NULL. Error: The specified module could not be found (126). GetProcAddress(0x606C0000 [LWBRK.DLL], "NSGetModule") called from "NSPR4.DLL" at address 0x60EC7975 and returned 0x606C214E. GetProcAddress(0x78860000 [WS2_32.DLL], "inet_addr") called from "WSOCK32.DLL" at address 0x7A001584 and returned 0x7886107A. GetProcAddress(0x78860000 [WS2_32.DLL], "WSAAsyncGetHostByName") called from "WSOCK32.DLL" at address 0x7A0019BB and returned 0x78864CFD. LoadLibraryA("C:\WIN95\SYSTEM\WS2_32.DLL") called from "WS2_32.DLL" at address 0x788616F1. LoadLibraryA("C:\WIN95\SYSTEM\WS2_32.DLL") returned 0x78860000. GetProcAddress(0xBFF60000 [USER32.DLL], "GetMonitorInfoA") called from "GKGFXWIN.DLL" at address 0x60370ADA and returned NULL. Error: The specified module could not be found (126). GetProcAddress(0x70100000 [RPCRT4.DLL], "I_RpcWindowProc") called from "OLE32.DLL" at address 0x65F3FDC9 and returned 0x701013F3. Second chance exception 0xC0000005 (Access Violation) occurred in "APPCOMPS.DLL" at address 0x600781DE. Is that information of any use? I can reproduce this crash 100%, so if anybody can suggest any diagnostics for me to try, or anywhere I can look for information in the complex confusing output of depends.exe let me know.
Reassigning to me. I'd like to believe that this was fixed by bug # 129794... anyone care to test with the tip?
Assignee: waterson → rjc
Marking as DUP of bug # 129794 since bug reporter mentions in comment # 13 that this works for him now. *** This bug has been marked as a duplicate of 129794 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Still crashes in exactly the same way on Windows 95 build 2002031903 Talckback TB4227061G
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 131497 has been marked as a duplicate of this bug. ***
I went searching backwards through http://ftp.mozilla.org/pub/mozilla/nightly/ hoping to find the last nightly before this started happening, but I got all the way to to the oldest achived win32 nightly (2002022016) and it was still crashing. 0.9.8 works fine.
Build 2002032708 Win 95 still crashes I noticed something interesting. If I run mozilla.exe -mail Then MailNews opens up just fine. If I then attempt to open a browser window from there, it crashes at that point. I can also run mozilla.exe -profilemanager And it does not crash until after I click the "Start Mozilla" button
Some comments for the crash reported in bug 130614 mention this bug... Both are startup crashes...but a look there might help narrow down the problem.
Summary: 0.9.9 crashes at startup on w95 in APPCOMPS.DLL [@nsWindowMediator::Assert] → 0.9.9 crashes at startup on w95 in APPCOMPS.DLL [@ nsWindowMediator::Assert]
Would someone care to try out this patch? (I don't have Win95.) It just protects usage of "mInner" by checking that it is non-null before using it in a few spots.
I have no build environment on my Windows 95 box, but if somebody can make a Win32 build with the patch, I would be delighted to test it.
Comment on attachment 76811 [details] [diff] [review] Protect "mInner" [s]email@example.com
Attachment #76811 - Flags: superreview+
Comment on attachment 76811 [details] [diff] [review] Protect "mInner" Verbal r=pavlov
Attachment #76811 - Flags: review+
Comment on attachment 76811 [details] [diff] [review] Protect "mInner" a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76811 - Flags: approval+
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
build 2002040303 still crashing on Windows 95. That fix was checked in this morning, right? Talkback TB4778218E
Reopening Still crashing in APPCOMPS.DLL on WIndows 95 with build 2002040503 , clean install, new profile. TB4866171M TB4866132W
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ah, according to the Talkback stack traces, this in actually crashing in Bookmarks: nsBookmarksService::ParseFavoritesFolder [d:\builds\seamonkey\mozilla\xpfe\components\bookmarks\src\nsBookmarksService.cpp, line 3225] Updating summary and reassigning to Ben (he may already have a similar bug).
Assignee: rjc → ben
Status: REOPENED → NEW
Summary: 0.9.9 crashes at startup on w95 in APPCOMPS.DLL [@ nsWindowMediator::Assert] → 0.9.9 crashes at startup on w95
James' recent crashes are already logged in bug 130614. Should I mark that a dup or should we close this as fixed again and focus our attention to bug 130614? I'll leave it up to the owners of this bug to decide.
Yes, let's call this fixed for the general case, and deal with Win95 separately.
Status: NEW → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Verified fixed...general case has been fixed. Latest Win95 incarnation of this can be found in bug 130614. Please go there with any new info.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.