Closed Bug 45842 Opened 24 years ago Closed 24 years ago

Crash on exit

Categories

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

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jamesrome, Assigned: adamlock)

References

Details

(Keywords: crash, embed, Whiteboard: [nsbeta3-])

Attachments

(2 files)

A stack dump of a crash on exit.
6.21 KB, text/plain
Details
WinNT stack trace of crash on exit
2.70 KB, text/plain
Details 
Build 2000061311
Every time I exit, I get a crash. Instruction 0x642090db referenced memory at 
0x00040005
Doesn't crash for me, maybe he needs to delete his prefs
wfm with 71908 win2k.  Please try with a later nightly and reopen if you're 
still seeing the problem.
Severity: normal → critical
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Keywords: crash
Resolution: --- → WORKSFORME
I deleted prefs.js (and lost all my mail!). But it still crashes on exit
James, what build did you download? This is working for me with 071908 mozilla
build on NT.
I just installed 2000071910, and it still crashes on exit.
OK, I just crashed on File|Quit twice in a row.  Reopening.  Tested with 071910
mozilla build on NT4
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
If you tested on a talkback build, possibly related to/dup of bug 43472
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crashes on exit. Every time → Crash on exit
I did test on a talkback build.  likely dupe.  James, were you using a talkback
build?
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
Yes, it was a talkback build
duping this against bug 43472.  pretty sure its the same.  

*** This bug has been marked as a duplicate of 43472 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
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.


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.
Un-duping this.  Maybe this is bug 44573
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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".


The Netscape PR2 does not crash.
This is working for me on 081108 mozilla build on NT4
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.  


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
Summary: Crash on exit → Crash in nsAbsoluteContainingBlock::DestroyFrames on exit
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.

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.
Summary: Crash in nsAbsoluteContainingBlock::DestroyFrames on exit → Crash on exit
looks like a crash in layout.
Assignee: asa → clayton
Status: REOPENED → NEW
Component: Browser-General → Layout
QA Contact: doronr → petersen
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?
Keywords: nsbeta3
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 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
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 ekrock@netscape.com to the CC list.  As ekrock 
may be the only Netscape person seing this.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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?
Assignee: clayton → asa
Status: REOPENED → NEW
Component: Layout → Browser-General
QA Contact: petersen → doronr
I believe that a reproducible browser crash-on-exit bug falls into XPApps. 
Reassigning to trudelle. Peter?
Assignee: asa → trudelle
Component: Browser-General → XP Apps
I agree, but I'm XPToolkit. reassigning to default xpapps owner, although I have
not seen this in recent builds.
Assignee: trudelle → don
QA Contact: doronr → sairuh
nav triage team:
this blocks tracking bug 7799, looks like it is a XPCOM issue, reassigning to
that component.
Assignee: don → rayw
Blocks: 7799
Component: XP Apps → XPCOM
QA Contact: sairuh → leger
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.

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.
Assignee: rayw → rogerl
Component: XPCOM → Javascript Engine
QA Contact: leger → pschwartau
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 -
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
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?  


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? 
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 -
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.
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. 

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...
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

No JS Engine bug apparent. Reassigning to Embedding:Docshell for a look -
Assignee: rogerl → adamlock
Status: REOPENED → NEW
Component: Javascript Engine → Embedding: Docshell
QA Contact: pschwartau → adamlock
need more reproducible test case.
Whiteboard: [nsbeta3-]
Trying to help with the crash bugs. But I cannot reproduce this one.
OS: Win2k
Build from branch pull on 10/19/2000
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.
Is this still an issue ? Is this now workforme ?
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 -
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Keywords: embed
Marking FIXED. Reopen if you think it still happens
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: