If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Trunk M120A Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ nsWindowWatcher::GetActiveWindow]

VERIFIED FIXED in mozilla1.2alpha

Status

()

Core
XUL
--
critical
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Greg K., Assigned: Brian Ryner (not reading))

Tracking

({crash, topcrash})

Trunk
mozilla1.2alpha
crash, topcrash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(6 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020906
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/20020906

For some reason, the iTools IMAP server at mail.mac.com is out of service at the
moment. After failing to connect to my account there, Mozilla alerted me that
the IMAP server is out of service with two consecutive alerts, then crashed.

Reproducible: Always

Steps to Reproduce:
1. Configure an IMAP account for a server that is out of service
2. Attempt to connect to that server.

Actual Results:  
Mozilla displayed two "out of service" alerts, then crashed.

Expected Results:  
Mozilla should not have crashed. I would say it should only have shown one
alert, but I'm not certain why two were shown. That's probably a separate issue.

Stack forthcoming.
(Reporter)

Comment 1

15 years ago
Created attachment 98252 [details]
Crash report generated by FizzillaCFM/2002090508 on 10.1.5 showing crash after nsWindowWatcher::GetActiveWindow
(Reporter)

Updated

15 years ago
Keywords: crash
(Reporter)

Comment 2

15 years ago
Experienced this crash again using FizzillaCFM/2002090608 on 10.1.5.
This is a topcrash that started showing up in 2002-09-06 04:00 builds.  Based on
a checkin window of
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-09-05+08%3A00&maxdate=2002-09-06+04%3A30&cvsroot=%2Fcvsroot
I strongly suspect bryner's checkin for bug 141295.  Note that at least some of
the stacks in talkback are different, and many of the steps to reproduce seem
different.
Assignee: mscott → bryner
Status: UNCONFIRMED → NEW
Component: Networking: IMAP → XP Toolkit/Widgets
Ever confirmed: true
Keywords: topcrash
Product: MailNews → Browser
Summary: Mozilla crashed after failure to connect to "Out-of-Service" IMAP server → Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ nsWindowWatcher::GetActiveWindow]
Blocks: 165012
Created attachment 98436 [details]
sumarry of talkback information for nsWindowWatcher::GetActiveWindow
(Assignee)

Comment 5

15 years ago
The only way I see to crash in GetActiveWindow is if mActiveWindow is an invalid
pointer.  I'll investigate.  Also, changing Platform/OS to All/All per talkback
info.
Status: NEW → ASSIGNED
OS: MacOS X → All
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.2alpha
(Assignee)

Comment 6

15 years ago
These are actually two distinct crashes, although they might have the same
cause.  I don't think we've gotten any talkback reports with the stack in this
bug.  We have several that appear to be a crash on showing a Navigator window
(from Startup in navigator.js).  I haven't been able to reproduce either one. 
Probably a timing issue that I haven't been able to hit yet.

I think we could bulletproof this by using an nsWeakPtr for mActiveWindow.  I'll
come up with a patch for that if I continue to not be able to reproduce this crash.
(Assignee)

Comment 7

15 years ago
Created attachment 98568 [details] [diff] [review]
bulletproof against dangling pointer

This is about the best I can do without a good way to reproduce the problem.
(Reporter)

Updated

15 years ago
Keywords: review

Comment 8

15 years ago
Comment on attachment 98568 [details] [diff] [review]
bulletproof against dangling pointer

This shouldn't be necessary; the system is (supposed to be) carefully
calibrated to not need this kind of second-tier protection. It's spackle on top
of the real problem, which is something else completely, and we're not even
sure it'll help. But I understand that, unable to reproduce the problem, it's a
shot.

Please add a big-ol' comment in the vicinity of the weakref declaration that
goes something like that.

I'd also like this to be a temporary patch: add some assertions to try to catch
the dangling pointer in action. And be prepared to remove the patch if it turns
out not to help. It assumes that the nsIDOMWindow we're handed supports
weakrefs. Ours do of course and it's unlikely we'll ever be handed one that
doesn't, but it is a bothersome assumption.

However I think your patch needs some null checks. mActiveWindow can be null,
so mActiveWindow.get() is problematic. Even then, CallQueryReferent (you know
this will be only the third place in the code where it's used, outside some
test suites!) doesn't like null parameters. I think you need to go with

if (mActiveWindow && mActiveWindow.get())
  CallQueryReferent.

(do_QueryReferent and do_GetWeakReference I believe are safe with nulls.)

r=me after addressing those issues.
Attachment #98568 - Flags: review+

Comment 9

15 years ago
not gonna hold 1.2a for this.
No longer blocks: 165012

Comment 10

15 years ago
Brian, are you still working on Dan's additions? Do you have a patch for sr=?
(Assignee)

Comment 11

15 years ago
I was hoping to get more specific info on how to reproduce this, instead of
papering over the problem.
(Assignee)

Comment 12

15 years ago
I found a case where we incorrectly tell WindowWatcher that a window is active
_after_ it has been unregistered.  This can happen if we receive a deactivate
after the window has been unregistered -- as part of deactivating the focus
controller, we go tell the window watcher that what used to be the focus
controller's active window is the current active window.  That's just wrong; we
should not be updating the active window from the focus controller when the
focus controller is deactivated.

The steps I used to reproduce this were to run mozilla /turbo from a command
prompt and refocus the command prompt window as turbo was starting up, then
running mozilla again (without /turbo) from a second command prompt.  Obviously
not typical user behavior, but I think there are likely other ways to trigger
the same situation.
(Assignee)

Comment 13

15 years ago
Created attachment 100085 [details] [diff] [review]
prevent spurious window watcher notifications

Comment 14

15 years ago
Created attachment 100275 [details]
Attaching stack trace and comments from M120A

This stack is currently the #1 topcrash on M120A and #3 topcrash on the trunk

Comment 15

15 years ago
Created attachment 100276 [details]
Attaching stack and comments from the trunk

Comment 16

15 years ago
Comment on attachment 100085 [details] [diff] [review]
prevent spurious window watcher notifications

r=danm
Attachment #100085 - Flags: review+

Comment 17

15 years ago
Comment on attachment 100085 [details] [diff] [review]
prevent spurious window watcher notifications

sr=alecf
Attachment #100085 - Flags: superreview+
(Assignee)

Comment 18

15 years ago
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 19

15 years ago
20020926 trunk builds on Winds and Mac.
 Configure an IMAP account for a server that is 'out of service' by killing the
mail server process. When attempting to connect to that server, an alert appears
describing that 'Could not connect to mail server xxx.mcom.com; the connection
was refused'. No crash.

 Brian also verified the fix.

Marking bug as verified.
Status: RESOLVED → VERIFIED

Comment 20

15 years ago
Adding 0x00000001 to summary for future reference since this crash was being
reported under that stack signature by Talkback.
Summary: Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ nsWindowWatcher::GetActiveWindow] → Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ 0x00000001 - nsWindowWatcher::GetActiveWindow]

Updated

15 years ago
Summary: Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ 0x00000001 - nsWindowWatcher::GetActiveWindow] → Trunk M120A Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ 0x00000001 - nsWindowWatcher::GetActiveWindow]

Comment 21

15 years ago
*** Bug 170693 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

15 years ago
Summary: Trunk M120A Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ 0x00000001 - nsWindowWatcher::GetActiveWindow] → Trunk M120A Mozilla crashed after failure to connect to "Out-of-Service" IMAP server [@ nsWindowWatcher::GetActiveWindow]
(Reporter)

Comment 22

15 years ago
*** Bug 183846 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 23

15 years ago
See bug 170693, comment 20 for a current crash stack involving
nsWindowWatcher::GetActiveWindow.
Crash Signature: [@ nsWindowWatcher::GetActiveWindow]
You need to log in before you can comment on or make changes to this bug.