Mac 2000-01-19-09-M13 .mozilla-mac-m13.sea.bin Actual results: [CRASH][PP]Crash when exit the seamonkey Expected Results: Should not crash when exit the seamonkey

I thought we had a bug on this. Yes, it's http://bugzilla.mozilla.org/show_bug.cgi?id=16693.

Should I need to reopen that bug instead of this bug? Or use this new bug?

Can we get a stack trace?

I can't repro a crash on shutdown with today's builds.

adding myself. that way, whether or not this is a dup of bug 16693 (or bug 7799, depending on how you view things :-), i can keep track for my testing...

Reassign to travis

after chatting w/sfraser (see below, lightly edited), i've added several folks to the cc list --feel free to change as needed, tho. <se> anyhow, wasn't sure if you meant that the crashes in bug 24441 and bug 16693 are two diff probs <se> [which by the stack traces, are diff] <se> or if you Were Referring To Something Else <smfr> one sec... <se> [another bug] <smfr> so, the crash in 24441 is nasty layout stuff, and needs a bug all of its own. <smfr> 16693 is a very different problem, and, we suspect, still fixed <smfr> and your crash with the tiny short log [bug 7799] is a third problem, as yet unidentified. <smfr> the 24441 crash should probably go to vidur, cc nisheeth, pollmann

Listen up, layout guys. here's the tail of the stack trace for this crash: 059DBA80 PPC 04D0A310 nsWebShell::Destroy()+001DC 059DB9D0 PPC 04CF7E48 NS_TotalWebShellsInExistence+00FB8 059DB990 PPC 04C7C9E4 nsCOMPtr_base::assign_with_AddRef(nsISupports*)+ 00048 059DB950 PPC 047A76D4 DocumentViewerImpl::Release()+00040 059DB910 PPC 047A7D88 DocumentViewerImpl::~DocumentViewerImpl()+001C0 059DB890 PPC 04C7C93C nsCOMPtr_base::~nsCOMPtr_base()+00030 059DB850 PPC 0471DBE8 nsXMLDocument::Release()+0000C 059DB810 PPC 044F9E3C nsDocument::Release()+00040 059DB7D0 PPC 0471D95C nsXMLDocument::~nsXMLDocument()+00148 059DB790 PPC 045BBA5C nsMarkupDocument::~nsMarkupDocument()+00064 059DB750 PPC 044F91D4 nsDocument::~nsDocument()+00190 which is why you guys have it.

Fix summary

M13 for now until I or Travis find out how reproducible this actually is ...

Ummmm, is this reproduceable by anyone? The stack is completely wrong here. I can't see how NS_TotalWebShellsInExistence could be in it the way it is. This means either the crash is completely trashing the stack, or the debugger isn't realizing the correct stack. Is this a local problem or seen from other machines? Has a full clobber build been done where we know v-tables aren't in question?

huang: can you describe the steps to reproduce this bug? Does it involve opening Mail? Is it reproducible?

Yes. It involve opening Mail... but it carsh when I exit the application. I had three times crashes yesterday, and I will try to reproduce again.....

Yes. It's reproducible, it's not every time, but 3 times crashes from 5. Provide the steps as following: 1) From Mozilla Installer, select IMAP mail profile from profile manager. (I had more than one migrated profiles) 2) From browser, select Tasks|mail 3) Type in the passwords to login to mail. 4) Select Inbox for reading latest Inbox messages (start from the latest message/ bottom message) 5) Read/View about more than 6 messages (latest 6 messages) 6) Select the other existing folders (1st level folder) which including existing messages (more than three messages). 7) Read/View 2 messages from that folder (from the latest/bottom message) 8) After above step and tried to close the mail. 9) Actual Results: Crash. (See below attached stack trace report) Expected Results: Shouldn't crash.

Changing qa assigned to pmock@netscape.com

OK, that's a totally different stack to the one in the earlier crash. Can you get logs for 3-4 crashes please? No need to attach them; just copy and paste in the section that starts "Calling chain using A6/R1 links" and ends "Return addresses on the stack".

Stack trace again by following the above steps: Copy/paste the "Calling chain using A6/R1 links" as your request: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 049AF334 05583940 PPC 049AC45C main+00190 055838A0 PPC 049ABDC8 main1(int, char**)+00580 055837B0 PPC 04781450 nsAppShellService::Run()+00018 05583770 PPC 046DF534 nsAppShell::Run()+00038 055836F0 PPC 046DFC4C nsMacMessagePump::DoMessagePump()+0003C 055836A0 PPC 046DFF20 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 05583650 PPC 075B71D4 Repeater::DoRepeaters(const EventRecord&)+00030 05583610 PPC 075B7E68 TimerPeriodical::RepeatAction(const EventRecord&)+ 00048 055835C0 PPC 075B79E8 TimerImpl::Fire()+00048

Return addresses on the stack Stack Addr Frame Addr ISA Caller 055838F8 PPC FFD19ED4 NewPtr+00028 055838BC 68K 04A0AAC6 055838A8 PPC 049AC45C main+00190 055838A4 68K 00AA69B6 0558387C 68K 04A0ACC6 05583830 68K 04A01A4A 055837E8 055837E0 PPC 0592BFFC NR_RegClose+00034 055837B8 055837B0 PPC 049ABDC8 main1(int, char**)+00580 05583778 05583770 PPC 04781450 nsAppShellService::Run()+00018 05583768 05583760 PPC 048D26D0 nsCOMPtr_base::assign_from_helper(const nsCOMPtr_he

After above crash, if I didn't restart the system, I got the crash again by following above steps..but no "Return addresses on the stack" this time: (I am still using yesterday "2000-01-19-09-M13 .mozilla-mac-m13.sea.bin" build) Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 049AF334 05583940 PPC 049AC45C main+00190 055838A0 PPC 049ABDC8 main1(int, char**)+00580 055837B0 PPC 04781450 nsAppShellService::Run()+00018 05583770 PPC 046DF534 nsAppShell::Run()+00038 055836F0 PPC 046DFC4C nsMacMessagePump::DoMessagePump()+0003C 055836A0 PPC 046DFF20 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 05583650 PPC 075B3444 Repeater::DoRepeaters(const EventRecord&)+00030 05583610 PPC 075B40D8 TimerPeriodical::RepeatAction(const EventRecord&)+ 00048 055835C0 PPC 075B3C58 TimerImpl::Fire()+00048

Crash again....no "Return addresses on the stack" this time.... Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 049AF334 05583940 PPC 049AC45C main+00190 055838A0 PPC 049ABDC8 main1(int, char**)+00580 055837B0 PPC 04781450 nsAppShellService::Run()+00018 05583770 PPC 046DF534 nsAppShell::Run()+00038 055836F0 PPC 046DFC4C nsMacMessagePump::DoMessagePump()+0003C 055836A0 PPC 046DFF20 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 05583650 PPC 075B3444 Repeater::DoRepeaters(const EventRecord&)+00030 05583610 PPC 075B40D8 TimerPeriodical::RepeatAction(const EventRecord&)+ 00048 055835C0 PPC 075B3C58 TimerImpl::Fire()+00048

ok, that's starting to look pretty consistent. This is some kind of mailnews timer thingy. Giving to ducarroz to look at.

Accepting

Hi Jeff, I am able to reproduce this problem now using today mac mozilla build 2000-01-20-08-m13 and getting a similar stack trace as Karen in TimerPeriodical and TimerImpl. I crash if I do not let seamonkey finish loading the message. The status bar reports that the message is loading and if I click on the close box on the upper left corner of Messenger, I crash. Note: I can't get today Mac commercial build to run. It's looks like the morning build is bad. Note: I can reproduce this problem on win32 commercial seamonkey build 2000-01-19-13-m13 and linux commercial seamonkey build 2000-01-19-16-m13. Changing platforms to ALL. I am using the same test message as Karen now. Here are the steps I used to reproduce this problem. Steps: 0) From Communicator 4.7, go to url: http://blues/users/daver/publish/snack/Dogfood_Snacks.html 1) Sent this page to yourself. 2) Launch Seamonkey 3) Open Messenger 4) Log into your IMAP mail. 5) Select the Dogfood Snack message that you sent from 4.7 6) As the status bar indicate that the "loading message...." Close the Messenger window. Note: If I let Messenger finish loading the message, I do not crash.

Yes, tody's build crash on startup! do we have a bug report for that?

Details, ducarroz? Mozilla/commercial? Stack?

Yes. I talked to Peter that this is the attached message that I was using. Clear status since it is also reproducible from Peter, too.

Peter, you can update the summary to narrow down this problem since it's your feature's bug now. Thanks.

The crash was (I don't crash anymore) in nsIOService::Init() when deleting the nsDNSService. After resetting my TCP/IP, the problem is gone.

Here the bug on crashing using the Mac commercial debug build. http://bugzilla.mozilla.org/show_bug.cgi?id=24439

my crash was a differnet one due to a problem with OpenTransport.

Yes, I can reproduce the crash, just close messenger while loading a message, don't need to send and get message, just click on an existing IMAP message.

Changing bug summary from: [CRASH][PP]Mac Crash in doc destruction on quit TO New bug summary: [Dogfood] Crash closing messenger when document hasn't finish loading. Jeff, You're right. You don't need to send or get message. /Peter

...but I cannot reproduce it every time, need to close messenger at the right time!

looks like this it a dup of bug 24385. *** This bug has been marked as a duplicate of 24385 ***

Verified as duplicate of bug 24385