26653 - Crash on quit when both mail window and browser open.

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[laurel]

Using feb04 commercial builds on linux rh6.0, NT 4.0

Not sure if this would be the same as bug #26608 or bug #26599

I'm able to crash consistently when I launch to mail then open a browser window
and Quit (from either mail or browser). Browser throbber not throbbing, page
fully loaded.  Mail window has not apparent activity, had not logged in yet.

1.  Launch mozilla -mail, directly to messenger (used single POP account
profile).
2.  I did not login to my POP mail account.
3.  Tasks|Navigator to open a browser window. Wait for page to fully load.
4.  File|Quit from either Browser or Mail Window.

Result:  crash.

Talkback incidents:

Linux rh 6.0:  http://cyclone/reports/incidenttemplate.cfm?bbid=4931974

NT 4.0:  http://cyclone/reports/incidenttemplate.cfm?bbid=4931953

Comment 1

[laurel]

Oh, happens using feb04 commercial on mac OS 9.0, too.  don't have crash report
for mac.

Comment 2

[Phil Peterson]

These stack traces claim to be in the PresShell. Over to rickg.

Comment 3

[laurel]

Added dogfood and beta to keywords... I'm hitting this all the time, so will
others.

Comment 4

[leger]

Not a dogfood bug, but need for beta. Putting on PDT+ radar for beta1.  Also, I 
am pretty sure there is a dup of this out there :-)

Comment 5

[lchiang]

http://bugzilla.mozilla.org/show_bug.cgi?id=26926 is the bug about exiting that 
was marked fixed recently (even though reported after this bug report).  I'm not 
sure if this bug report is the same one or not.  Just a fyi so that if the same, 
this bug doesn't get marked worksforme and gets marked a duplicate instead.

Comment 6

[David Härdeman]

The same behaviour can be seen [on win build 2000021216] by:
1) Launcing mozilla like normal (browser)
2) start mail/news
3) close browser
4) close mail/news

Comment 7

[rickg]

Phil -- ordinarily, I'd track something like this down, even though it's not 
gecko specific. However, I'll be out at a customer site this week and can't get 
to this. Can you track this down, please?

Comment 8

[Phil Peterson]

David, can you take a look into this? Thanks.

Comment 9

[davidmc]

I will see if the crash is obvious from looking in nsPresShell.cpp.
If the bug is more subtle, then my chances of figuring it out are nil.

Comment 10

[davidmc]

The more recent stack crawls also suggest a strong relation to the problem in 
revoking outstanding PLEvents as described in the bug lchiang mentions:
http://bugzilla.mozilla.org/show_bug.cgi?id=26926

I'm going to try reproducing this now, but since the cause is very likely in the 
management of events, there is no chance I'll be able to fix it, or even grasp 
the underlying reasons. (I'm better at designing event systems in languages using 
automatic collection, and cannot crash due to haywire C++ reference patterns.)

Comment 11

[davidmc]

So far I can't see a problem when I attempt reproducing on the Mac with build 
from sources pulled yesterday from the tree.  I've tried several ways of starting 
either mail first or browser first, and then either closing in some order or just 
quitting.  However, absence of memory protection on the Mac might hide some 
memory access that would fail on other platforms.  I'm reassigning to nisheeth as 
the fixer of the related 26926 bug for further judgment about whether it's the 
same bug.

Comment 12

[Nisheeth Ranjan]

My build is in progress and I should have an answer for you soon.

Comment 13

[Nisheeth Ranjan]

This crash is unrelated to the crash in bug 26926.  Re-assigning this to 
Travis because he made a bunch of changes to the global window a couple of 
weeks back.  Here's the stack trace:

GlobalWindowImpl::ClearAllTimeouts() line 3267 + 12 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x0cc4a8b4, 
nsIDOMDocument * 0x00000000) line 233
DocumentViewerImpl::~DocumentViewerImpl() line 366
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x0cd14030) line 306 + 
134 bytes
nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 
0x00000000) line 417
nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 
788
nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 527
nsWebShell::Destroy(nsWebShell * const 0x0ccbc140) line 3667
nsXULWindow::Destroy(nsXULWindow * const 0x0ccb9844) line 335
nsWebShellWindow::Close(nsWebShellWindow * const 0x0ccb9888) line 394
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f840) line 453
nsWindow::DispatchEvent(nsWindow * const 0x0ccbc5c4, nsGUIEvent * 0x0012f840, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f840) line 514
nsWindow::DispatchStandardEvent(unsigned int 101) line 534 + 15 bytes
nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long * 
0x0012fa88) line 2089
nsWindow::WindowProc(HWND__ * 0x00cd07c4, unsigned int 16, unsigned int 0, long 
0) line 671 + 27 bytes

Comment 14

[travis]

*** Bug 27600 has been marked as a duplicate of this bug. ***

Comment 15

[Mike Kaply [:mkaply]]

I believe I found an easier way to recreate this. (On Win NT)

Create a new profile, but do not configure any mail or news items.
Start the browser. Select Tasks->Mail. When the profile manager comes up, click 
cancel. Then close the Mail window.

The trap happens every time.

The problem seems to be that a bad timer got into the list some how. It's next 
pointer is 0xdddddddd which causes the trap. It appears to be related to the 
insertion of the dummy_timer in the list.

Comment 16

[Mike Kaply [:mkaply]]

This appears related to the changes put in on bug #25269.

Comment 17

[James Everingham]

removing PDT+, changing to beta2, too risky

Comment 18

[Ray Yang]

Just happened to me, using build 2000022820 (the milestone M14 build). Win98, 
PII. I opened mozilla, then used the little mail button on the lower left-hand 
corner, then closed both windows using the close button in the upper right 
hand-corner of the windows. 

Comment 19

[don]

Moving to M15.  Hmmm, this happens more often than I realized ...

Comment 20

[travis]

Fixed

Comment 21

[Karen Huang]

Cc me & adding comments here since problem is still occurring on Mac 9.0.
Will attach MacsBug report.

Comment 22

[Karen Huang]

Attachment: Attached MacsBug report

Comment 23

[laurel]

I sent a copy of Karen's macsbug report to Simon Fraser (and a couple others) to
evaluate against known open mac bug reports.  Simon believes the crash in
Karen's macsbug (attachment 7196 [details]) report to be a duplicate of bug #32067. He's
included a copy of the macsbug report in 32067 and commented accordingly.

When I verify this (26653) situation I'll go on NT and linux basis, since Mac
has its own set of problems.

Comment 24

[laurel]

Using 2000-04-06-10m15 commercial build NT 4.0 
Using 2000-04-06-10m15 commercial build Linux rh6.0:

I can't reproduce this now.
I haven't seen this for awhile.
Marking verified and will keep an eye out for it.