45842 - Crash on exit

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[James Rome]

Build 2000061311
Every time I exit, I get a crash. Instruction 0x642090db referenced memory at 
0x00040005

Comment 1

[Eric Hodel]

Doesn't crash for me, maybe he needs to delete his prefs

Comment 2

[Blake Ross]

wfm with 71908 win2k.  Please try with a later nightly and reopen if you're 
still seeing the problem.

Comment 3

[James Rome]

I deleted prefs.js (and lost all my mail!). But it still crashes on exit

Comment 4

[Asa Dotzler [:asa]]

James, what build did you download? This is working for me with 071908 mozilla
build on NT.

Comment 5

[James Rome]

I just installed 2000071910, and it still crashes on exit.

Comment 6

[Asa Dotzler [:asa]]

OK, I just crashed on File|Quit twice in a row.  Reopening.  Tested with 071910
mozilla build on NT4

Comment 7

[Blake Ross]

If you tested on a talkback build, possibly related to/dup of bug 43472

Comment 8

[Asa Dotzler [:asa]]

I did test on a talkback build.  likely dupe.  James, were you using a talkback
build?

Comment 9

[Alan S. Jones]

I see a crash on exit after i have used Mozilla a little while.  
NOT if i just open and close.

This is on Windows 95, several builds including 7-19-00

Comment 10

[James Rome]

Yes, it was a talkback build

Comment 11

[Asa Dotzler [:asa]]

duping this against bug 43472.  pretty sure its the same.  

*** This bug has been marked as a duplicate of 43472 ***

Comment 12

[Shiva Thirumazhusai]

Bug 43472 is mainly in Linux and partially on MAC. It will be useful if you can
add steps to re-produce and configuration information . Simple launch, browse 
for sometime and File Exit doesnot seem to crash or it is not easily 
reproducible in Windows.

Comment 13

[James Rome]

Well, I am on NT4.0 SP6a, and ity does it all the time for me, no matter what I 
do. I usually click the X in the top right to exit.

Comment 14

[Asa Dotzler [:asa]]

Un-duping this.  Maybe this is bug 44573

Comment 15

[R'ykandar Korra'ti]

This also reproduces for me:

NT 4.0 SP 6a on Intel PII/350
Mozilla M16 - Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m16) Gecko/20000613

This is a talkback build. This is also the ONLY version of Mozilla ever
installed on this machine.

Steps to reproduce:
launch browser
click to Bugzilla
click any other page
exit by clicking on close gadget in upper right

Result: crash on exit
Expected: clean close

Two crash dialogue text examples:

Example 1:
NSPR: EventReceiver: mozilla.exe - Application Error
The instruction at "0x642090db" referenced memory at "0xffffffff". The memory
could not be "read".

Example 2:
mozilla.exe - Application Error
The instruction at "0x642039de" reference memory at "0x00000014". The memory
could not be "read".

Comment 16

[James Rome]

The Netscape PR2 does not crash.

Comment 17

[Asa Dotzler [:asa]]

This is working for me on 081108 mozilla build on NT4

Comment 18

[Alan S. Jones]

Windows 95 build 2000081108.
I sometimes see the crash on exit and sometimes do not.  It depends on how long 
I have been using Mozilla.  A normal open mozilla then closse (click on X) 
usually will not crash.  

In playing around I did find that if i load Mozilla then go stright to  
http://www.brainjar.com/ let it finish loading I can exit and crash.  Several 
others in #mozillazine also how this forced a crash on exit.

MOZILLA caused an invalid page fault in module <unknown> at 0000:000000a7.

I did get send a talkback of this under this e-mail addres ID: TB15652283G.  If 
anyone wants to attach it to see if it is worth anything.

I assume this crash is the same as others are seeing, but maybe not.  The simple 
DR WATSON stuff seemed much the same.

Yes this page is screwy with Mozilla they are detecting us wrong and using 
layer.  I can't convence the author to fix his code till Mozilla/NS6 is more 
stable in his eyes.  

Comment 19

[Hixie (not reading bugmail)]

http://cyclone/reports/incidenttemplate.cfm?bbid=15652283
Alan asked me to attach the report, but I'm not exactly sure what to attach...
there's stacks and stacks of info there! ;-)

The top of the call stack is:
Call Stack:    (Signature = 0x000000a7 6e1e1f0d)      0x000000a7
 nsAbsoluteContainingBlock::DestroyFrames
 nsPositionedInlineFrame::Destroy
 nsLineBox::DeleteLineList
 nsBlockFrame::Destroy
 nsLineBox::DeleteLineList nsBlockFrame::Destroy
 nsLineBox::DeleteLineList nsBlockFrame::Destroy
 nsFrameList::DestroyFrames nsContainerFrame::Destroy
 nsFrameList::DestroyFrames

Comment 20

[Alan S. Jones]

I am curious if others seeing this crash on exit are seeing it in the same spot 
as the info posted by and for me.  This bug may need to be split up to several 
crash on exit issues.

Comment 21

[Alan S. Jones]

I have split my bug off of crash after going to http://www.brainjar.com/ and 
exiting.  I am seeing both the original crash mentined here only after using 
mozilla a while and this one.  

When i crash after using Mozilla after while with talkback build like orignal 
reporter I do not get a talkback report.  So it must be after talkback stuff is 
finished.

For those interested my new crash is bug 48871

Changing the subject back to the original.

Comment 22

[Asa Dotzler [:asa]]

looks like a crash in layout.  

Comment 23

[ekrock's old account (dead)]

I have seen this crash on exit every time on WinNT 4.0 SP4 in every build for at
least a month now. (Sorry for not reporting sooner, I'd been told this was a
known bug of PR2.) Still seeing in Commercial 8/15 build. Drop by my cube
anytime if you wish to reproduce. It *is* a Talkback build, but unfortunately,
it never gives you the opportunity to submit a Talkback report.

Nominating nsbeta3 as a crasher. Could we please reassign this bug to someone
other than clayton as he's on vacation this week?

Comment 24

[Marc Attinasi]

From the stack provided this looks exactly like a known problem with abs / rel
positioning, buster's bug 42372. Since I can see no other specifics I am closing
this as a dup of 42372.

*** This bug has been marked as a duplicate of 42372 ***

Comment 25

[Alan S. Jones]

Marc Attinasi an others PLEASE IGNORE THE STACK TRACE I PUT,  I SPLIT THAT OFF 
TO ANOTHER BUG THAT I LATER DUPED.  THE STACK TRACE DOES NOT APPLY TO THIS BUG.

##$@#$@ I wish i could yank that comment ouf of bugzilla.

I am reopening this bug an adding [e-mail] to the CC list.  As ekrock 
may be the only Netscape person seing this.

Comment 26

[Alan S. Jones]

I am changing this compoent back to browser general where it started (sorry 
all).  It does not look like a layout untill I put my other stupid bug in here.

ekrock, can you help us find the correct compoent for this crasher?

Comment 27

[ekrock's old account (dead)]

I believe that a reproducible browser crash-on-exit bug falls into XPApps. 
Reassigning to trudelle. Peter?

Comment 28

[Peter Trudelle]

I agree, but I'm XPToolkit. reassigning to default xpapps owner, although I have
not seen this in recent builds. 

Comment 29

[johng]

nav triage team:
this blocks tracking bug 7799, looks like it is a XPCOM issue, reassigning to
that component.

Comment 30

[Ray Whitmer]

Where is the stack dump identifying this particular bug as an XPCOM bug?

If I go to brainjar, I can dup that one which is clearly a layout bug.

If I go to a few links off of the mozilla page, I can duplicate other crashes.  
But none where XPCOM seems implicated.

Comment 31

[Ray Whitmer]

Attachment: A stack dump of a crash on exit.

Comment 32

[Ray Whitmer]

Well, I was able to produce a JS crash and no XPCOM crash, and there is no info 
on an XPCOM crash, so I am marking this as JS.

Comment 33

[Phil Schwartau]

Using Mozilla WinNT binary, BuildID 2000082313.
OS: WinNT 4.0 (SP5)

Cannot reproduce crash on exit no matter what I try; marking WORKSFORME.

If anyone is still crashing on exit, please reopen, but note: 
many stack traces look like this at the top:

gc_root_marker( etc. ) 
JS_HashTableEnumerateEntries( etc. )
js_GC( etc. ) 
     .
     .
     .

This does NOT necessarily imply that this is a bug in JS Engine.
If you get this, it is crucial to find the value of (char*)he->value
in gc_root_marker at the crash point, via a debugger. 


For example, in bug 48304 we found a crash in gc_root_marker had
 
        (char*)he->value = "member_val->field_val"

In bug 43466, 

        (char*)he->value = "window_object"

So if you get a trace ending in gc_root_marker, please find the value
of this string!!!

On the other hand, if anyone can verify the WorksForMe, please do so; thanks - 

Comment 34

[ekrock's old account (dead)]

Reopening. This happens *every single time* on *every build* on my machine. If 
you want to reproduce, please just drop by my cube--seriously! As I noted 
before, I never get the opportunity to file a Talkback report, for whatever 
reason. Here's the crash alert message:

The instruction at "0x642090db" referenced memory at "0x0031004d". The memory 
could not be "read". Click on OK to terminate the application.

Comment 35

[Phil Schwartau]

I dropped by Eric's cube and witnessed the crash on exit. The OS is WinNT SP4. 
It swaps memory very, very slowly, and Eric has told me that the OS is in bad 
shape right now and actually needs to be reinstalled.

On this machine, Mozilla crashes on exit every time, no matter what
you do. For example, just bring it up, then close it. Nothing has 
to be done. Obviously, the OS is suspect, but as Eric points out,
no other application he runs on this machine crashes on exit.

Unfortunately, nothing can be done to solve this without a stack trace.
The box does not currently have Visual C++ on it. We decided to wait 
until the OS is reinstalled next week, install Visual C++, and try to 
get a good trace, including char*)he->value

Comment 36

[Alan S. Jones]

I hate to ask this question, but what happens if things don't crash after the OS 
is reinstalled?    Would it be better to install VC++ before?  

Comment 37

[ekrock's old account (dead)]

It's taking a long time to back everything up anyway, so if someone wants to 
install VC++ on my machine (in its current !@#$%ed up state) Friday or Monday, 
they're free to. Do we have a volunteer? Can we ask IS to do this? 

Comment 38

[Phil Schwartau]

Have installed VC++ on Eric's laptop. For what it's worth, here is a stack
trace of a crash on exit, using his commercial binary build:

DIMM! 642090db()
USER32! 77e7e1e2()
USER32! 77e71a3d()
NTDLL! 77f7637b()
GKWIDGET! 60b51205()
NTDLL! 77f69d9e()
KERNEL32! 77f1a02f()
MSVCRT! 780055a9()
KERNEL32! 77f1ba3c()


Will return on Monday to do a debug build, to get a better trace -

Comment 39

[David Krause]

I am seeing something similar to this practically everytime I exit mozilla on
Windows NT 4.0 SP6.  This has been happening for at least the last month with
pretty much every day's build.  Here is the error:

OleMainThreadWndName: mozilla.exe - Application Error
The instruction at "0x?????" reference memory at "0x?????". The memory could
not be "read."  Click on OK to terminate the application.

Comment 40

[Phil Schwartau]

UPDATE:

I never did try do a debug build of Mozilla on Eric's machine, because
I finally was able to reproduce the crash-on-exit on my own WinNT box.
I still have not been able to duplicate it on a commercial build, however. 

OS: WinNT 4.0 (SP5) 
Using Mozilla nightly binaries: 2000082508
                                2000090110
                                2000090508


For some reason, recently I have been unable to do a WinNT debug build.
The build process is halting with errors in cmd.exe. So I can't get
a debug stack trace of the crash on exit. 

The crash-on-exit is sporadic - in fact I only reproduced it once,
and then only on build 2000082508. But I've stumbled across something
that works every time. It is related to bug 22425 (which I've reopened):

Open Mozilla, click "Debug|DOM Viewer", then click "Refresh" once.
Then quit Mozilla: CRASH with the exact same "OleMainThreadWndName" messagebox 
that David mentions in the comment above. This happens for Mozilla nightlies:

                              2000082508
                              2000090508


For 2000090110, I actually crash as soon as I click "Refresh" once,
without even trying to quit Mozilla. For the other two nightlies,
I can also make this happen, but only if I click "Refresh" 2 or 3 times.


GOAL: I hope I can do a debug build on WinNT and get a stack trace!!!
In the meantime, I hope that bug 22425 might shed some light on this bug. 

Comment 41

[Phil Schwartau]

Using Mozilla debug tip build 2000-09-07 9PM Pacific Time on WinNT.
OS: WinNT 4.0 (SP5)

Finally able to do a debug build on WinNT. Cannot seem to get the DOM viewer
to come up (see previous entry). However, I crash on exit anyway.  Steps: 


1. Launch Mozilla
2. Close Mozilla via the upper-right corner "x"


Does not crash every time, but every time it does, I get the same stack trace.
I will attach the full trace below. Here is a synopsis:


nsDSURIContentListener::DoContent( etc.) line 106 + 24 bytes
nsDocumentOpenInfo::DispatchContent( etc.) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest( etc.) line 233 + 16 bytes
nsResChannel::OnStartRequest( etc.) line 691
nsFileChannel::OnStartRequest( etc.) line 634
nsOnStartRequestEvent::HandleEvent( etc.) line 210 + 26 bytes
nsStreamListenerEvent::HandlePLEvent( etc.) line 97 + 12 bytes
PL_HandleEvent( etc.) line 589 + 10 bytes
PL_ProcessPendingEvents( etc.) line 526 + 9 bytes
_md_EventReceiverProc( etc.) line 1059 + 9 bytes
USER32! 77e71820()
00f52da0()


NOTE: on starting Mozilla, I get four dialog boxes that say:

nsDebug::Assertion
###!!! ASSERTION: node in map twice: '(node->mContent != aNode->mContent)|| 
((node->mContent==nsNull) && (node->mStyle != aNode->mStyle))',  
file d:\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1907


I don't know if that's relevant...

Comment 42

[Phil Schwartau]

Attachment: WinNT stack trace of crash on exit

Comment 43

[Phil Schwartau]

Here are the alert boxes WinNT and Visual C++ present when I crash:

OleMainThreadWndName: mozilla.exe - Application Error
The instruction at '0x01d74095' referenced memory at 0x00000000'.
The memory could not be 'read'.


Microsoft Visual C++
Unhandled exception in mozilla.exe(DOCSHELL.DLL): 0xC0000005: Access Violation

Comment 44

[Phil Schwartau]

No JS Engine bug apparent. Reassigning to Embedding:Docshell for a look - 

Comment 45

[Judson Valeski]

need more reproducible test case.

Comment 46

[cata]

Trying to help with the crash bugs. But I cannot reproduce this one.
OS: Win2k
Build from branch pull on 10/19/2000

Comment 47

[ekrock's old account (dead)]

I'm no longer seeing this on WinNT 4.0 SP4 (same physical machine) now that I've 
done a clean reinstall of the OS and all my apps and data.

Comment 48

[Frank Tang]

Is this still an issue ? Is this now workforme ?

Comment 49

[Phil Schwartau]

Using Mozilla MN6 branch binary 2000102309 on WinNT.

Marking WORKSFORME, as I don't see it anymore, either. 
Please reopen if anyone is still seeing it -

Comment 50

[James Rome]

The M18 Build has been better. It did crash once on exit for me when I was in 
several IMAP windows and clicked X to close them

Comment 51

[David Krause]

I was seeing a crash on exit everytime with each day's build on WinNT.  I am no
longer see crashes on exit everytime like I was.

Comment 52

[Adam Lock]

Marking FIXED. Reopen if you think it still happens