78857 - ###!!! ASSERTION: nsDOMEvent not thread-safe: 'owningThread ==

Status: VERIFIED FIXED

(Core :: DOM: Events, defect, P2)

Description

[timeless]

y:/tmp/obj-sparc-sun-solaris2.7/dist/bin: ./mozilla -splash
./run-mozilla.sh ./mozilla-bin -splash
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:/tmp/idl/lib:/tmp/glib/lib:/tmp/qt-2.2.0/lib
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
File descriptors set to 512
Type Manifest File: /tmp/obj-sparc-sun-solaris2.7/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
###!!! ASSERTION: failed to create encoder: '0', file 
/tmp/mozilla/intl/uconv/src/nsUNIXCharset.cpp, line 396
###!!! Break: at file /tmp/mozilla/intl/uconv/src/nsUNIXCharset.cpp, line 396
###!!! ASSERTION: unable to use nl_langinfo(CODESET): '0', file 
/tmp/mozilla/intl/uconv/src/nsUNIXCharset.cpp, line 320
###!!! Break: at file /tmp/mozilla/intl/uconv/src/nsUNIXCharset.cpp, line 320
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=32
WEBSHELL+ = 1
Note: verifyreflow is disabled
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: '(!((rv) & 
0x80000000))', file /tmp/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2951
###!!! Break: at file /tmp/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2951
###!!! ASSERTION: NS_ENSURE_TRUE(cssDecl) failed: 'cssDecl', file 
/tmp/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 982
###!!! Break: at file /tmp/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 982
CanUnload_enumerate: skipping native
###!!! ASSERTION: nsDOMEvent not thread-safe: 'owningThread == 
NS_CurrentThread()', file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528
###!!! Break: at file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528

Details, yet another attempt by me to build and run w/ Qt. Other bugs already 
exist for some of these assertions [Bug 77300, Bug 78854, Bug 78855], and I 
will probably file more for the remainining assertions.

This build is based on this morning's sourceball and a cvs update from sometime 
in the morning (it takes a while to build).

A profile manager window can/will appear for a moment, however it dies very 
quickly (and my use of MIX w/ a bad twm results in me not actually seeing the 
content because twm is waiting for me to place the window).

I actually am getting grief from the plugin component, so I moved 
libgkplugin.so  plugin.xpt out of components/ , zapped component.reg and ran 
regxpcom [more bugs].

This might be a dupe of Bug 69573.
I'm having trouble running mozilla w/ gdb due to swap/tmp constraints so if we 
can debug w/ printf's that'd be nice.

Comment 1

[timeless]

Oh, right, here's the crash from regxpcom
WARNING: nsJSRuntimeService is missing, file 
/tmp/mozilla/modules/libpref/src/nsPrefService.cpp, line 719
Runtime mismatch, so leaking context!
JS API usage error: 1 contexts left in runtime upon JS_DestroyRuntime.
JS engine warning: 27 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
JS engine warning: leaking GC root 'res->input' at 151fe8
JS engine warning: 1 GC root remains after destroying the JSRuntime.
                   This root may point to freed memory. Objects reachable
                   through it have not been finalized.
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 
0', file /tmp/mozilla/xpcom/build/nsXPComInit.cpp, line 505
###!!! Break: at file /tmp/mozilla/xpcom/build/nsXPComInit.cpp, line 505
###!!! ASSERTION: nsDOMEvent not thread-safe: 'owningThread == 
NS_CurrentThread()', file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528
###!!! Break: at file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528

After careless consideration, i'm going to assume my bug is better than the bsd 
bug and close it.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

So it is a crash(?). Crashes should have the crash keyword and severity critical.

Comment 3

[Ken]

Since the bug summary is just about the nsDOMEvent assertion, I thought I would 
add that you can reproduce the assertion in an embedding case (I am running 
under win2k) with just this (added as a project under mozilla\embedding\tests\)

#include <nsEmbedAPI.h>

int main(void)
{
   NS_InitEmbedding(nsnull,nsnull);
   NS_TermEmbedding();
   return 0;
}

The assertion happens after the return, as static objects, like nsDomEvent, are 
destructing -- the problem is that the owningThread was never set in this case. 
Shouldn't it be set during nsDomEvent initialization?

Comment 4

[Nisheeth Ranjan]

timeless, is the assertion only fired on exiting Mozilla?  If not, what does one
have to do to reproduce the assertion.

Lets focus on just one problem in this bug, please.  If this is an assertion,
then this is not a crash bug.  If we do crash in certain conditions, lets open a
new bug, attach a stack trace of the crash, and describe how to reproduce the
crash.  Thanks!  

Removing the crash keyword.

Comment 5

[Ken]

For me (embedding) this is not a crash. It is only an assertion because of the 
bizarre way the singleton nsDOMEvent is created without ever initializing the 
owning thread member var.

See the code above to reproduce the assertion for an embedded case.

Comment 6

[timeless]

sorry, i'm not certain.  and my build environment is almost entirely gone.

I think that runyonkj's analysis is good enough to go on.

Comment 7

[Gustavo Verdun]

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

Comment 8

[Gustavo Verdun]

See bug 92995 for the root cause of this bug. The fix should be simple assuming
there are no platform/c++ compiler problems with the sizeof operator on classes
with v-tables here.

Can someone raise this to 'topembed'?

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

topembed so adding nsbranch+ as well.

Setting milestone for 0.9.4 with priority, but the fix should also go into 0.9.2
branch.

Comment 10

[saari (gone)]

->0.9.5

Comment 11

[chris hofmann]

are we any closer on this one?

Comment 12

[saari (gone)]

I'll give the proposed solution in bug 92995 a try, hopefully later today

Comment 13

[saari (gone)]

Other than a test harness or QT build, is there any way I can test this? Test
patch coming up...

Comment 14

[saari (gone)]

Attachment: give this a whril

Comment 15

[Ken]

Verified! The patch fixes the assertion. To the 0.9.4 branch, please?

Comment 16

[Marek Z. Jeziorek]

The patch was verified by [e-mail]. It looks that it needs r= and sr=
before it can be checked into 0.9.4 (it has PDT+). Could someone organize it,
since 0.9.4 is clsing VERY VERY soon.

Comment 17

[Johnny Stenback (:jst)]

Saari, if you can't leave gEventPool as a static member of nsDOMEvent, then move
the declaration of gEventPool into nsDOMEvent.cpp, leaving it in the header will
do bad things (one instance per .cpp file that #includes the nsDOMEvent header).
Also, remove the commented out declaration of gEventPool in nsDOMEvent.cpp in
stead of commenting it out.

Other than that, sr=jst

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

What jst said, r=heikki...

Comment 19

[saari (gone)]

Attachment: Cleaned up patch, should be ready to go

Comment 20

[saari (gone)]

fix checked in on branch and trunk

Comment 21

[Vladimir Ermakov]

Can one of engeneers please verify this bug?

Comment 22

[lchiang]

[e-mail] or timeless - can you help to verify this?  

Comment 23

[Ken]

fix confirmed on the 0.9.4 branch

Comment 24

[Vladimir Ermakov]

verifying per Ken's coments