239373 - Assertion in nsGenericElement.cpp: cycle from textbox.xml

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[tenthumbs]

For the last week or so I've occasionally seen this at shutdown.

###!!! ASSERTION: nsGenericElement's event listener manager hash not empty at
shutdown!: 'sEventListenerManagersHash.entryCount == 0', file
nsGenericElement.cpp, line 783
Break: at file nsGenericElement.cpp, line 783

I haven't found a simple test case yet but one thing to try is to:
1) go to http://www.dell.com/
2) enter "outlet" in the search box and click the link
3) select one of the refurbished links, like monitors, and start looking.

This is on my Linux gtk1 trunk build.

I don't know how serious this is.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is crossplatform; I've seen this quite some time on windows too.

Comment 2

[Nicholas Allen]

The assertion indicates a leak is happening.  Originally this lead to a crash
but I believe that's no longer possible.

Comment 3

[Bob Clary [:bc] (inactive)]

I see this if I start, create a new profile, then exit.

Last part of Log

WARNING: cannot post event if not initialized, file
c:/work/mozilla_source/trunk/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 144
###!!! ASSERTION: nsGenericElement's event listener manager hash not empty at
shutdown!: 'sEventListenerManagersHash.entryCount == 0
', file
c:/work/mozilla_source/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 784
Break: at file
c:/work/mozilla_source/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 784
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
###!!! ASSERTION: Potential deadlock between
nsComponentManagerImplMonitor@2ef578 and Lock@26cff78: 'Error', file
c:/work/mozilla_so
urce/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
Break: at file
c:/work/mozilla_source/trunk/mozilla/xpcom/threads/nsAutoLock.cpp, line 299
nsStringStats
 => mAllocCount: 1
 => mReallocCount: 0
 => mFreeCount: 1
 => mShareCount: 0
 => mAdoptCount: 0
 => mAdoptFreeCount: 0
nsStringStats
 => mAllocCount: 18872
 => mReallocCount: 2234
 => mFreeCount: 18871
 => mShareCount: 19798
 => mAdoptCount: 2875
 => mAdoptFreeCount: 2874
stack on winxp

NTDLL! 77f75a58()
nsDebugImpl::Assertion(nsDebugImpl * const 0x002e6d50, const char * 0x01655d48,
const char * 0x01655d1c, const char * 0x01655cd0, int 784) line 272
nsDebug::Assertion(const char * 0x01655d48, const char * 0x01655d1c, const char
* 0x01655cd0, int 784) line 109
nsGenericElement::Shutdown() line 784 + 35 bytes
Shutdown(nsIModule * 0x00a3f368) line 359
nsGenericModule::Shutdown() line 344 + 10 bytes
nsGenericModule::~nsGenericModule() line 247
nsGenericModule::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsGenericModule::Release(nsGenericModule * const 0x00a3f368) line 249 + 142 bytes
nsDll::Shutdown() line 380 + 18 bytes
nsFreeLibrary(nsDll * 0x00a1a100, nsIServiceManager * 0x00000000, int 3) line 275
nsFreeLibraryEnum(nsHashKey * 0x00a1a190, void * 0x00a1a100, void * 0x0012fe84)
line 344 + 64 bytes
hashEnumerate(PLDHashTable * 0x002ef7e8, PLDHashEntryHdr * 0x0099642c, unsigned
int 24, void * 0x0012fe68) line 115 + 26 bytes
PL_DHashTableEnumerate(PLDHashTable * 0x002ef7e8, int (PLDHashTable *,
PLDHashEntryHdr *, unsigned int, void *)* 0x100146f0 hashEnumerate(PLDHashTable
*, PLDHashEntryHdr *, unsigned int, void *), void * 0x0012fe68) line 619 + 34 bytes
nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x10064420
nsFreeLibraryEnum(nsHashKey *, void *, void *), void * 0x0012fe84) line 303 + 21
bytes
nsNativeComponentLoader::UnloadAll(nsNativeComponentLoader * const 0x002ef7a0,
int 3) line 961
nsComponentManagerImpl::UnloadLibraries(nsIServiceManager * 0x00000000, int 3)
line 3139 + 22 bytes
nsComponentManagerImpl::Shutdown() line 878
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 776 + 11 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 184 + 10 bytes
GRE_Shutdown() line 468 + 7 bytes
main(int 1, char * * 0x002e2638) line 1724 + 5 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()

Comment 4

[tenthumbs]

The "potential deadlock" stuff is bug 209804. I don't know if they're related.

Comment 5

[Johnny Stenback (:jst)]

The deadlock assertions are unrelated to these assertions, AFAIK.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: (Av1) patch textbox.xml [Checkin: See comment 10]

I saw the assertion when starting and closing calendar. After commenting out
code etc, I found that the problem was in textbox.xml. That caches the
inputfield, but doesn't clear the reference on shutdown. This makes things
leak, and causes the assertion.

Comment 7

[[e-mail]]

Comment on attachment 193340 [details] [diff] [review]
(Av1) patch textbox.xml
[Checkin: See comment 10]

Sorry, I can't reproduce this. Without the patch, I can launch the create
profile wizard without generating the assert, while even with the patch, I open
history preferences and get the assert on shutdown.

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 193340 [details] [diff] [review]
(Av1) patch textbox.xml
[Checkin: See comment 10]

The profile manager doesn't contain a textbox, so it won't prodice the assert.
I got it to reproduce by simply starting mozilla -calendar, and then closing
it. (calendar does have a textbox in the main window)
If there are more ways to reproduce, then maybe other widgets need the same
fix.

Comment 9

[[e-mail]]

Comment on attachment 193340 [details] [diff] [review]
(Av1) patch textbox.xml
[Checkin: See comment 10]

I'm sorry, but I can neither reproduce the assert at all these days, nor do I know why the patch might help. Try a peer for nsGenericElement?

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 193340 [details] [diff] [review]
(Av1) patch textbox.xml
[Checkin: See comment 10]

I checked in the toolkit part.
Removing the sr-request, as i don't know who can review it.
Neil, who should review the xpfe part? Can you try to find somebody, and drive this in, or just kill the bug? (I have begged enough. I really don't feel like begging more, so i'm not going to spend more of my time on this bug.)

Comment 11

[Boris Zbarsky [:bzbarsky]]

For what it's worth, doing the textbox thing shouldn't really matter (if it were required, then any browser window would leak, since browser windows have the URL bar textbox)...

Comment 12

[Alex Vincent [:WeirdAl]]

Bug 314199 may be a dupe of this bug, but it finally has some reproducible steps.

Comment 13

[Alex Vincent [:WeirdAl]]

This bug may be a dupe of bug 241518, which was just fixed.

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> (From update of attachment 193340 [details] [diff] [review] [edit])
> (I have begged enough. I really don't feel like
> begging more, so i'm not going to spend more of my time on this bug.)

Neil, (Boris):
I'm working on bug 282187,
and wonder if there is a reason (for me) not to port/copy this to SM ?
From my understanding, the 'action to CDATA' rewrite part is fine,
and the addition of |this.mInputField = null;| is debated !?
This comment is somehow an sr? request.

Comment 15

[[e-mail]]

Well both bindings have changed somewhat since, so we already have an expanded action block. I have no idea whether the nulling is useful though.

Comment 16

[Serge Gautherie (:sgautherie)]

Comment on attachment 193340 [details] [diff] [review]
(Av1) patch textbox.xml
[Checkin: See comment 10]

(In reply to comment #15)
> Well both bindings have changed somewhat since, so we already have an expanded
> action block. I have no idea whether the nulling is useful though.

Following our emails, the constructor has already been updated, but not the destructor.
Requesting sr? for the remaining Xpfe part, with/without (= tell me) the nulling line.

Comment 17

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #16)
> Requesting sr? for the remaining Xpfe part, with/without (= tell me) the
> nulling line.

the nulling line is the part that tries to fix the bug, by breaking a circular reference. Removing it makes the patch useless.
(And no, it might not fix all instances of this assertion. There might be other similar problems. It just fixes the one that happens when using calendar.)

Comment 18

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1-XPFE) <textbox.xml> (remaining part)

Per comment 16

Comment 19

[Robert Kaiser]

xpfe textbox.xml is not used by SeaMonkey any more, is there still any relevance to this or can we close the bug?

Comment 20

[Serge Gautherie (:sgautherie)]

Comment on attachment 213136 [details] [diff] [review]
(Bv1-XPFE) <textbox.xml> (remaining part)


Obsolete, per comment 19.

Comment 21

[Serge Gautherie (:sgautherie)]

(In reply to comment #19)
> is there still any relevance to this or can we close the bug?

Let's R.Fixed this bug.
Open new bugs if this still happens elsewhere.