crashes on shutdown

RESOLVED FIXED in mozilla1.3beta

Status

()

Core
Networking
P1
critical
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: blizzard, Assigned: Darin Fisher)

Tracking

({crash})

Trunk
mozilla1.3beta
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
All of a sudden, I'm getting tons of crashes on shutdown.  This is just in the
last day or so.  The stack is munged, and looks something like this:

#1543 0x4020511a in nsInputStreamReadyEvent::Release (this=0x455c6b80)
    at ../../../mozilla/xpcom/io/nsStreamUtils.cpp:113
#1544 0x40259b0c in nsCOMPtr_base::~nsCOMPtr_base (this=0x4125f1ac, 
    __in_chrg=0) at ../../../mozilla/xpcom/glue/nsCOMPtr.cpp:64
#1545 0x40205d23 in nsInputStreamReadyEvent::~nsInputStreamReadyEvent (
    this=0x455c6afc, __in_chrg=3)
    at ../../../mozilla/xpcom/io/nsStreamUtils.cpp:55
#1546 0x4020511a in nsInputStreamReadyEvent::Release (this=0x455c6ac8)
    at ../../../mozilla/xpcom/io/nsStreamUtils.cpp:113
#1547 0x40259b0c in nsCOMPtr_base::~nsCOMPtr_base (this=0x4125f23c, 
    __in_chrg=0) at ../../../mozilla/xpcom/glue/nsCOMPtr.cpp:64
#1548 0x40205d23 in nsInputStreamReadyEvent::~nsInputStreamReadyEvent (
    this=0x455c6a44, __in_chrg=3)
(Assignee)

Comment 1

15 years ago
-> me (fun, fun, fun!)
Assignee: dougt → darin
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
(Assignee)

Comment 2

15 years ago
hmm, so some sort of recursive death.  were you doing anything in particular
when you closed the last browser window / quit mozilla?
Status: NEW → ASSIGNED
Keywords: crash
(Assignee)

Comment 3

15 years ago
blizzard: do you think you could attach more of the stack... i'm interested in
the values of some of the parameters... e.g., is it oscillating between two
nsInputStreamReadyEvents or is the value of |this| monotonically increasing?
(Assignee)

Comment 4

15 years ago
i think this might be caused by the code in the destructor:

    virtual ~nsInputStreamReadyEvent()
    {
        if (mNotify) {
            //
            // whoa!! looks like we never posted this event. take care not to
            // delete mNotify on the calling thread (which might be the wrong
            // thread).
            //
            nsCOMPtr<nsIInputStreamNotify> event;
            NS_NewInputStreamReadyEvent(getter_AddRefs(event),mNotify,mEventQ);
            mNotify = 0;
            if (event)
                event->OnInputStreamReady(nsnull);
        }
    }

the OnInputStreamReady method tries to call PostEvent.  but, if we are shutting
down, PostEvent might fail (maybe we have stopped accepting events on the main
UI thread event queue).  in this case we will enter the destructor for |event|.
and loop endlessly :(

patch coming up...
(Assignee)

Comment 5

15 years ago
Created attachment 113769 [details] [diff] [review]
v1 patch

prevent recursive death
(Assignee)

Comment 6

15 years ago
blizzard: can you determine what thread this is?  i doubt it could be one of the
necko threads, since we join with all the necko threads from the xpcom-shutdown
event.  could this be from one of the IMAP threads?
(Assignee)

Updated

15 years ago
Attachment #113769 - Flags: superreview?(blizzard)
Attachment #113769 - Flags: review?(dougt)
(Reporter)

Comment 7

15 years ago
I'll try this patch to see if it helps.

In general, I need to do a lot of stuff to cause this to happen.  I can't get
more of the stack since I think the stack is actually hosed.
(Assignee)

Comment 8

15 years ago
blizzard: why do you think the stack is hosed?  the dtor in fact can call
itself, and that's what's happening here.  my patch eliminates that possibility.
(Reporter)

Comment 9

15 years ago
Comment on attachment 113769 [details] [diff] [review]
v1 patch

sr=blizzard

Feels hacky, but OK.
Attachment #113769 - Flags: superreview?(blizzard) → superreview+

Comment 10

15 years ago
Comment on attachment 113769 [details] [diff] [review]
v1 patch

yup.
Attachment #113769 - Flags: review?(dougt) → review+
(Assignee)

Comment 11

15 years ago
bliz: it is hacky, but the warning message will help us track down the culprit.
 in fact, i'll make it a NS_NOTREACHED instead so folks will be able to easily
trap this in the debugger.
(Assignee)

Comment 12

15 years ago
Comment on attachment 113769 [details] [diff] [review]
v1 patch

seeking drivers approval for 1.3 beta...
Attachment #113769 - Flags: approval1.3b?

Comment 13

15 years ago
Comment on attachment 113769 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #113769 - Flags: approval1.3b? → approval1.3b+
(Assignee)

Comment 14

15 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.