File/Quit crash on Netscape6-mac.sea.bin build/Mozilla build

VERIFIED DUPLICATE of bug 43472

Status

()

Core
Layout
P3
blocker
VERIFIED DUPLICATE of bug 43472
18 years ago
7 years ago

People

(Reporter: Grace Bush, Assigned: clayton)

Tracking

({crash})

Trunk
PowerPC
Mac System 8.5
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+][dogfood-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Not sure of component here- seamonkey (commercial and mozilla ) launches 
reliably. 
Mozilla installed build, netscape..sea.bin file build and Netscape Installed 
build will crash on file/quit.
I can reliably reproduce on commercial bin file build and commercial installed 
build but on the Mozilla installed build sporadically- no pattern noticeable.  I 
cannot reproduce this on 
 MacMozillaInstaller.sea.bin build
Can also be seen on G4 9.0 systems and 8.6 systems

talkback report from netscape build is: (other talkback reports from 
netscape.sea.bin file and from 8.6 installed build will be added later)
Incident ID 11667027 
 Trigger Time 
               2000-06-02 12:52:37 
 Email Address 
               gbush@netscape.com 
 User Comments 
               file/quit (after browsing) 
 Build ID
               2000060208 
 Product ID
               Netscape6 
 Platform ID
               MacOS 
 Stack Trace

AppleJava + 0x2b6d8 (0x0a09e668) 
AppleJava + 0x2643c (0x0a0993cc) 
AppleJava + 0x1fadc (0x0a092a6c) 
MRJ22Jitc.01 + 0x1053c (0x0ab3738c) 
MRJ22Jitc.01 + 0x86e08 (0x0abadc58) 
AppleJava + 0x2098 (0x0a075028) 
AppleJava + 0x1624c (0x0a0891dc) 
AppleJava + 0x15984 (0x0a088914) 
AppleJava + 0x121f0 (0x0a085180) 
AppleJava + 0x1210c (0x0a08509c) 
AppleJava + 0x11be0 (0x0a084b70) 
AppleJava + 0x11c38 (0x0a084bc8) 
MRJ22Jitc.01 + 0x1266c (0x0ab394bc) 
MRJ22Jitc.01 + 0x12438 (0x0ab39288) 
MRJ22Jitc.01 + 0x11dac (0x0ab38bfc) 
MRJ22Jitc.01 + 0x11940 (0x0ab38790) 
MRJ22Jitc.01 + 0x116a8 (0x0ab384f8) 
AppleJava + 0x1b884 (0x0a08e814)

Comment 1

18 years ago
Yup, I see this with today's build too.  Clearly not an installer issue since 
the .sea.bin blob is showing the same symptoms.

Comment 2

18 years ago
Adding crash to keyword field.
Keywords: crash

Comment 3

18 years ago
Putting on dogfood+ radar.
Assignee: asa → sgehani
Severity: normal → blocker
Keywords: dogfood
QA Contact: jelwell → gbush
Whiteboard: [dogfood+][M16Blocker]

Comment 4

18 years ago
This is *not* an installer issue.  This happens with the blob too.  Will attach 
stack crawl.  Need to reassign.

Updated

18 years ago
Summary: File/Quit crash on Netscape6-mac.sea.bin build/ Mozilla Installed build → File/Quit crash on Netscape6-mac.sea.bin build/Mozilla build

Comment 5

18 years ago
Created attachment 9732 [details]
Stack crawl of crash on File|Quit per 06-06-08-2000 build

Comment 6

18 years ago
Simon, 
Can you reassign to the appropriate owner?  cvs blame reflects troy/tbogard as 
the last folks to have touched the last function in the stack crawl sometime ago, 
both of whom are no lonegr here.  Thanks.
Assignee: sgehani → sfraser

Comment 7

18 years ago
I can't reproduce this, and the bug contains two different stacks. Not sure what 
to do with it...

Comment 8

18 years ago
QA reports that they don't get a crash on quit with current M16 bits. Please 
reopen if you can reproduce.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 9

18 years ago
Steps to reproduce:
1> Install using the installer *or* expand the blob stuffit archive.
2> Launch the build (which happens automatically if you install).
3> Wait for the default homepage (home.netscape.com/index1.html) to load.
4> Choose File|Quit.
5> Observe crash into debugger with stack I attached above.

Note:
(*) I have observed this consistently teh first time I run the product after 
installing.
(*) After the running a given build the first time, the crash is intermittent.

Reopening per discussion with Simon.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 10

18 years ago
samir: Please try to reproduce under the following conditions:
1. Change your screen depth from millions to thousands (or vice versa)
2. Allocate more memory to the app.

I suspect this is another symptom of low memory.

Comment 11

18 years ago
adding milestone
Target Milestone: --- → M16

Updated

18 years ago
Whiteboard: [dogfood+][M16Blocker] → [dogfood+][M16Blocker] awaiting testing

Comment 12

18 years ago
Still crashing with the same stack.

1> I changed from millions of colors to thousands.
2> I double the app memory from 16 MB to 32 MB.

Updated

18 years ago
Whiteboard: [dogfood+][M16Blocker] awaiting testing → [dogfood+][M16Blocker]

Comment 13

18 years ago
This could be caused by bug 41996. If someone can repro in a debug build, then we 
can try applying a patch.
(Reporter)

Comment 14

18 years ago
doubling the memory (16 to 32) works for me

Comment 15

18 years ago
Grace,
I'd argue we don't know if it works for you since this is intermittent.

Comment 16

18 years ago
Per Seamonkey Leads mtg today, removing this from dogfood+ status.  We do need 
to understand this though, so putting on [nsbeta2+] radar.
Keywords: nsbeta2
Whiteboard: [dogfood+][M16Blocker] → [nsbeta2+][dogfood-]

Comment 17

18 years ago
I'm not a good owner for this bug, because I've never been able to reproduce it, 
and it's not just Mac. Reassigning to module owner.
Assignee: sfraser → asa
Status: REOPENED → NEW
QA Contact: gbush → doronr

Comment 18

18 years ago
asa..if you can anyone in the net community to reproduce his consistently...this 
would help alot.  Thanks!
(Reporter)

Comment 19

18 years ago
adding stack trace from commercial build 2000061214M17
incident 12316055
Stack Trace

0x80410014 
ViewportFrame::Destroy() [nsViewportFrame.cpp, line 143] 
FrameManager::~FrameManager() [nsFrameManager.cpp, line 372] 
FrameManager::Release() [nsFrameManager.cpp, line 352] 
PresShell::~PresShell() [nsPresShell.cpp, line 1046] 
PresShell::Release() [nsPresShell.cpp, line 960] 
nsCOMPtr_base::~nsCOMPtr_base() [nsCOMPtr.cpp, line 49] 
DocumentViewerImpl::~DocumentViewerImpl() [nsDocumentViewer.cpp, line 433] 
DocumentViewerImpl::Release() [nsDocumentViewer.cpp, line 344] 
nsCOMPtr_base::assign_with_AddRef() [nsCOMPtr.cpp, line 58] 
.__as__28nsCOMPtr<16nsIContentViewer>FP16nsIContentViewer [nsCOMPtr.h, line 580] 
nsDocShell::Destroy() [nsDocShell.cpp, line 1318] 
nsWebShell::Destroy() [nsWebShell.cpp, line 1586] 
nsXULWindow::Destroy() [nsXULWindow.cpp, line 422] 
nsWebShellWindow::Destroy() [nsWebShellWindow.cpp, line 1731] 
nsWebShellWindow::Close() [nsWebShellWindow.cpp, line 357] 
nsAppShellService::~nsAppShellService() [nsAppShellService.cpp, line 96] 
nsAppShellService::Release() [nsAppShellService.cpp, line 109] 
nsXPCWrappedNative::~nsXPCWrappedNative() [xpcwrappednative.cpp, line 390] 
nsXPCWrappedNative::Release() [xpcwrappednative.cpp, line 71] 
nsXPCWrappedNative::JSObjectFinalized() [xpcwrappednative.cpp, line 94] 
WrappedNative_Finalize() [xpcwrappednativejsops.cpp, line 690] 
js_FinalizeObject() [jsobj.c, line 1483] 
js_GC() [jsgc.c, line 1034] 
js_ForceGC() [jsgc.c, line 765] 
js_DestroyContext() [jscntxt.c, line 205] 
JS_DestroyContext() [jsapi.c, line 788] 
mozJSComponentLoader::~mozJSComponentLoader() [mozJSComponentLoader.cpp, line 
172] 
mozJSComponentLoader::Release() [mozJSComponentLoader.cpp, line 181] 
nsSupportsHashtable::ReleaseElement() [nsHashtable.cpp, line 392] 
_hashEnumerate() [nsHashtable.cpp, line 95] 
PL_HashTableEnumerateEntries() [plhash.c, line 413] 
nsHashtable::Enumerate() [nsHashtable.cpp, line 233] 
nsSupportsHashtable::~nsSupportsHashtable() [nsHashtable.cpp, line 397] 
nsComponentManagerImpl::Shutdown() [nsComponentManager.cpp, line 363] 
NS_ShutdownXPCOM() [nsXPComInit.cpp, line 626] 
main() [nsAppRunner.cpp, line 1097] 
.__start 

Comment 20

18 years ago
Checking with rickg on proper assignment of this since FrameMgr issue involved. 
 Asa...I don't think your gonna fix it...are ya? :-)

Comment 21

18 years ago
not gonna fix it but I can confirm it on mozilla bits and others have reported
seeing it as well.  Happens the first File->Quit on a new install and not again
until new install.

Comment 22

18 years ago
Removing myself from cc...don't need to be on cc for this.

Comment 23

18 years ago
M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 24

18 years ago
Is this still happening?

I don't understand how a pdt+ bug isn't assigned to anyone who's going to fix 
it.  We need to get this to an engineer.

Comment 25

18 years ago
over to Layout.
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen

Comment 26

18 years ago
still happening on 6/28 commercial and mozilla bits (OS 9 tested here)

Comment 27

18 years ago

*** This bug has been marked as a duplicate of 43472 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 28

18 years ago
Marking verified dup of 43472.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.