18979 - [DOGFOOD] [REGRESSION] Mozilla crashes on exit / quit

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Scott MacGregor]

Whenever I try to exit with the M12 11/16 release build, I crash on exit.

Here's a stack trace courtesy of David B.
PR_EnterMonitor(PRMonitor * 0x00000041) line 76 + 3 bytes
_pl_GetEventCount(PLEventQueue * 0x030caf10) line 465 + 12 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x030caf10) line 492 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x01c304ac, unsigned int 0x0000c101, unsigned int
0x00000000, long 0x030caf10) line 972 + 9
bytes
USER32! 77e71820()
030caf10()

I know dougt made some thread changes yesterday. I'm going to start with him
in the hopes that he can help us find the right owner for this bug.

I would nominate that this be a blocker on the tree today but the tree
seems to be open already.

Comment 1

[Doug Turner (:dougt)]

I do see the crash in mozilla, but in a different repeatable location.  I may
have a slightly older build.  Here is what I am seeing.

After main() is existed, some nsCOMPtr's get destroyed.  Among them are
nsXULAttributes.  These contain AtomImpl's.  The destructor of these atoms what
to remove themselves from the gAtomHashTable which at this time is null.  I get
about 20 asserts like this, than I crash in nsRegistry when trying to lock a
null pointer.

ccing scc and Saari.  you guys have any ideas?

Comment 2

[Doug Turner (:dougt)]

here is the sc of the crash:

PR_Lock(PRLock * 0x00000000) line 228 + 3 bytes
NR_RegClose(void * 0x02448140) line 2355 + 11 bytes
nsRegistry::Close(nsRegistry * const 0x02448300) line 461 + 12 bytes
nsRegistryDataSource::~nsRegistryDataSource() line 140
nsRegistryDataSource::`scalar deleting destructor'(unsigned int 0x00000001) +
15 bytes
nsRegistryDataSource::Release(nsRegistryDataSource * const 0x0244faf0) line 181
+ 134 bytes
CompositeDataSourceImpl::Release(CompositeDataSourceImpl * const 0x023d7ac0)
line 584 + 12 bytes
nsCOMPtr<nsIRDFCompositeDataSource>::~nsCOMPtr<nsIRDFCompositeDataSource>()
line 408
nsXULElement::Slots::~Slots() line 3565 + 22 bytes
nsXULElement::Slots::`scalar deleting destructor'(unsigned int 0x00000001) + 15
bytes
nsXULElement::~nsXULElement() line 319 + 31 bytes
nsXULElement::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXULElement::Release(nsXULElement * const 0x022d6a40) line 478 + 137 bytes
nsSupportsArray::Clear(nsSupportsArray * const 0x022b3790) line 318 + 36 bytes
nsSupportsArray::DeleteArray() line 63
nsSupportsArray::~nsSupportsArray() line 40
nsSupportsArray::`vector deleting destructor'(unsigned int 0x00000001) + 81
bytes
nsSupportsArray::Release(nsSupportsArray * const 0x022b3790) line 58 + 129
bytes
nsCOMPtr<nsISupportsArray>::~nsCOMPtr<nsISupportsArray>() line 408
nsXULElement::~nsXULElement() line 371 + 22 bytes
nsXULElement::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXULElement::Release(nsXULElement * const 0x022b38f0) line 478 + 137 bytes
nsSupportsArray::Clear(nsSupportsArray * const 0x022b38a0) line 318 + 36 bytes
nsSupportsArray::DeleteArray() line 63
nsSupportsArray::~nsSupportsArray() line 40
nsSupportsArray::`vector deleting destructor'(unsigned int 0x00000001) + 81
bytes
nsSupportsArray::Release(nsSupportsArray * const 0x022b38a0) line 58 + 129
bytes
nsCOMPtr<nsISupportsArray>::~nsCOMPtr<nsISupportsArray>() line 408
nsXULElement::~nsXULElement() line 371 + 22 bytes
nsXULElement::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXULElement::Release(nsXULElement * const 0x022b39b0) line 478 + 137 bytes
nsSupportsArray::Clear(nsSupportsArray * const 0x02397360) line 318 + 36 bytes
nsSupportsArray::DeleteArray() line 63
nsSupportsArray::~nsSupportsArray() line 40
nsSupportsArray::`vector deleting destructor'(unsigned int 0x00000001) + 81
bytes
nsSupportsArray::Release(nsSupportsArray * const 0x02397360) line 58 + 129
bytes
nsCOMPtr<nsISupportsArray>::~nsCOMPtr<nsISupportsArray>() line 408
nsXULElement::~nsXULElement() line 371 + 22 bytes
nsXULElement::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXULElement::Release(nsXULElement * const 0x0200b080) line 478 + 137 bytes
nsCOMPtr<nsIContent>::~nsCOMPtr<nsIContent>() line 408
$E265() + 13 bytes
_CRT_INIT(void * 0x01650000, unsigned long 0x00000000, void * 0x00000001) line
236
_DllMainCRTStartup(void * 0x01650000, unsigned long 0x00000000, void *
0x00000001) line 289 + 17 bytes
NTDLL! 77f69d9e()
KERNEL32! 77f1a02f()
doexit(int 0x00000000, int 0x00000000, int 0x00000000) line 392
exit(int 0x00000000) line 279 + 13 bytes
mainCRTStartup() line 345
KERNEL32! 77f1ba3c()

Comment 3

[rhp (gone)]

I see this crash and another one in Necko when it can't write all its data on
exit. I backed out all of dougt's changes from last night and still had the
same problem so I am looking into other changes from yesterday.

- rhp

Comment 4

[Doug Turner (:dougt)]

does updating nsprpub and rebuild fix this for you?

Comment 5

[rhp (gone)]

For me it didn't...and I was wondering how this would be the problem since I
thought that Commercial builds are all clobber builds.

- rhp

Comment 6

[Doug Turner (:dougt)]

This looks to be saari's change to nsEventStateManager.cpp on line 119 made
this last saturday.  Assigning to him.

Comment 7

[Peter Trudelle]

Needs a target milestone.

Comment 8

[Peter Trudelle]

targetting M13

Comment 9

[Scott MacGregor]

Hmm...can we really say we have a M12 release we are going to give out to the
public if it crashes every time you exit the app? This seems like it should be
an M12 stopper to me.....Thoughts?

Comment 10

[Peter Trudelle]

If it was anywhere but Exit I'd agree, but 99 times out of 100 the thing crashes
before I exit, so I'm not too broken up by this.  In any case, nobody has marked
it dogfood, so it isn't PDT+, and I've been told to move all non-PDT+ bugs to
M13 or beyond.

Comment 11

[cpratt]

Just a quick note that in the 19991207xx builds (08 on Mac and Linux, 12 on
Win32), if you start the browser and select File | Quit, it crashes. I'd agree
with mscott on this one.

Comment 12

[Scott MacGregor]

I wonder if we shouldn't nominate this for dogfood then? I'm going to nominate
for dogfood even though it may be a little late. This will allow PDT to
determine if they want to hold M12 for this or go ahead with the M13 assignment.

Comment 13

[cpratt]

Changing summary to make it easier to find...

Comment 14

[rickg]

It's important to fix for beta, but not dogfood.

Comment 15

[saari (gone)]

Hey, my static nsCOMPtrs are long gone, the nsAtom crash on exit is no more. Fixed.

Comment 16

[leger]

Adding crash keyword

Comment 17

[John Unruh]

Verified.