Closed Bug 130234 Opened 18 years ago Closed 18 years ago

0.9.9 crashes at startup on w95

Categories

(Core Graveyard :: RDF, defect, critical)

x86
Windows 95
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: dmyurych, Assigned: bugs)

References

Details

(Keywords: crash, regression, Whiteboard: [ADT2])

Attachments

(1 file)

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?
Keywords: 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
Assignee: asa → adamlock
Status: UNCONFIRMED → NEW
Component: Browser-General → Embedding: APIs
Ever confirmed: true
QA Contact: doronr → mdunn
Keywords: nsbeta1
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
really reassign
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]
Attached patch Protect "mInner"Splinter Review
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.
Keywords: adt1.0.0
Target Milestone: --- → mozilla1.0
Keywords: adt1.0.0
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+
Keywords: adt1.0.0
adt1.0.0+ (on ADT's behalf) for checkin into 1.0.
Keywords: adt1.0.0adt1.0.0+
Whiteboard: [ADT2]
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 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 ago18 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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.