130183 - Mozilla crashes playing some Cult3D plugins [js_MarkGCThing]

Status: VERIFIED DUPLICATE of bug 180182

(Core :: XPConnect, defect)

Description

[R.K.Aa.]

Testing with current CVS, Linux - RH7.1
--

Cult3D's main site still claim "No support" for Netscape 6. But seen from a
practical perspective, that's not entirely true anymore. Installing Cult3D for
Mozilla was resolved as WFM in bug 92644 medio August last year.

To install on Linux:

Go to http://www.cult3d.com
Click small button/image near bottom reading "Get cvcore Cult3D"
Grab the "Linux 2.0" (old) or "redhat" rpm (it's compatible with RH7.1, at least
with the common compat libs installed)

Download and install the rpm, which lands in any old netscape 4 dir
Then:
ln -s /usr/lib/netscape/plugins/cult3d/libcult3dplugin.so ~/.mozilla/plugins
or symlink to wherever mozilla plugins are located.

Cult3d is somewhat flaky on mozilla, but has a good chance of working without a
crash. It may have some bugs on its own, one seemingly just surfaced in bug 130106.

Just found another one that is happening in Mozilla code though - to reproduce:

-install the plugin if you haven't
-restart moz to make it see the plugin
-go to http://www.cult3d.com/
-click the pic of an orange can (lower left on the page, small pic, a demo)

If you don't crash right away, choose another "label" for the can.
Backtrace from a non-debug:

#0  0x4008b278 in js_MarkGCThing () from libmozjs.so
#1  0x4008b332 in gc_root_marker () from libmozjs.so
#2  0x4007b005 in JS_DHashTableEnumerate () from libmozjs.so
#3  0x4008b60f in js_GC () from libmozjs.so
#4  0x4008b3a5 in js_ForceGC ()   from libmozjs.so
#5  0x4006bb27 in JS_GC ()   from libmozjs.so
#6  0x412f9f6b in nsJSContext::Notify ()   from libjsdom.so
#7  0x401723ef in nsTimerImpl::Process ()   from libxpcom.so
#8  0x4017246b in handleMyEvent ()   from libxpcom.so
#9  0x4016e3bb in PL_HandleEvent ()   from libxpcom.so
#10 0x4016e2b5 in PL_ProcessPendingEvents ()   from /libxpcom.so
#11 0x4016f2ff in nsEventQueueImpl::ProcessPendingEvents ()   from libxpcom.so
#12 0x4117a606 in event_processor_callback ()   from libwidget_gtk.so
#13 0x4117a368 in our_gdk_io_invoke ()   from libwidget_gtk.so
#14 0x40395a7a in g_io_unix_dispatch (source_data=0x82db358, 
    current_time=0xbfffe800, user_data=0x83170d0) at giounix.c:137
#15 0x40397055 in g_main_dispatch (dispatch_time=0xbfffe800) at gmain.c:656
#16 0x40397659 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#17 0x403977e8 in g_main_run (loop=0x83170e0) at gmain.c:935
#18 0x402ab65b in gtk_main () at gtkmain.c:524
#19 0x4117aae5 in nsAppShell::Run ()   from libwidget_gtk.so
#20 0x4115a9ca in nsAppShellService::Run ()   from libnsappshell.so
#21 0x0805201b in main1 ()
#22 0x08052925 in main ()
#23 0x404f5627 in __libc_start_main (main=0x80527ec <main>, argc=1, 
    ubp_av=0xbfffec04, init=0x804c9fc <_init>, fini=0x8053f34 <_fini>, 
    rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbfffebfc)
    at ../sysdeps/generic/libc-start.c:129

Severity "major", since cult3d still claims "no support for NS6". 
So installing it at all can be said to be at user's own risk I guess.

Nevertheless.. "Mozilla shouldn't crash".

Comment 1

[Phil Schwartau]

Note: I do not have a working Linux debug build at the moment.
Whoever does should print the gc_root_marker and JS_DHashTableEnumerate
frames to see what object is being rooted. A stack like this typically
indicates a dangling root. For example, someone has freed memory
containing a JS GC root, without calling JS_RemoveRoot{,RT}. 

Comment 2

[timeless]

Assertion failure: flags != GCF_FINAL, at /home/timeless/mozilla/js/src/jsgc.c:816
Abort trap - core dumped
./run-mozilla.sh -g -d gdb51 ./mozilla-bin /root/coredumps/mozilla-bin.7319.core
[freebsd, cvs build, today, some patches to intl and window watcher, nothing interesting near jseng]

#2  0x281cdb7d in JS_Assert (s=0x281d8132 "flags != GCF_FINAL", file=0x281d8040 "/home/timeless/mozilla/js/src/jsgc.c", ln=816) at /home/timeless/mozilla/js/src/jsutil.c:173
173         abort();
(gdb)
#3  0x281736b3 in js_MarkGCThing (cx=0x90bdc00, thing=0x90dac70, arg=0x0) at /home/timeless/mozilla/js/src/jsgc.c:816
816         JS_ASSERT(flags != GCF_FINAL);
(gdb)
#4  0x281737dd in js_MarkGCThing (cx=0x90bdc00, thing=0x8fde720, arg=0x0) at /home/timeless/mozilla/js/src/jsgc.c:899
899                     GC_MARK(cx, JSVAL_TO_GCTHING(v), name, arg);
(gdb)
#5  0x281737dd in js_MarkGCThing (cx=0x90bdc00, thing=0x8f18ab8, arg=0x0) at /home/timeless/mozilla/js/src/jsgc.c:899
899                     GC_MARK(cx, JSVAL_TO_GCTHING(v), name, arg);
(gdb)
#6  0x28173996 in gc_root_marker (table=0x80d1020, hdr=0x8d47784, num=553, arg=0x90bdc00) at /home/timeless/mozilla/js/src/jsgc.c:955
955             GC_MARK(cx, JSVAL_TO_GCTHING(v), rhe->name ? rhe->name : "root", NULL);
(gdb) up
#7  0x28159246 in JS_DHashTableEnumerate (table=0x80d1020, etor=0x28173860 <gc_root_marker>, arg=0x90bdc00) at /home/timeless/mozilla/js/src/jsdhash.c:599
599                 op = etor(table, entry, i++, arg);
(gdb)
#8  0x28173de6 in js_GC (cx=0x90bdc00, gcflags=0) at /home/timeless/mozilla/js/src/jsgc.c:1155
1155        JS_DHashTableEnumerate(&rt->gcRootsHash, gc_root_marker, cx);
(gdb)
#9  0x28173a50 in js_ForceGC (cx=0x90bdc00) at /home/timeless/mozilla/js/src/jsgc.c:979
979         js_GC(cx, 0);
(gdb)
#10 0x28140aa4 in JS_GC (cx=0x90bdc00) at /home/timeless/mozilla/js/src/jsapi.c:1644
1644        js_ForceGC(cx);
(gdb)

#11 0x2984e8c8 in nsJSContext::Notify (this=0x90c94c0, timer=0x91c5880) at /home/timeless/mozilla/dom/src/base/nsJSEnvironment.cpp:1569
1569      ::JS_GC(mContext);
Current language:  auto; currently c++
(gdb)

#12 0x282da294 in nsTimerImpl::Process (this=0x91c5880) at /home/timeless/mozilla/xpcom/threads/nsTimerImpl.cpp:332
332           mCallback.i->Notify(this);

My crash was using FreeBSD, No plugins, and trying to send an email. So i'm moving this to JSEng ... Full stack (97 frames) available, I don't understand what you want me to do, this stack should be valid for a while, if necessary, I can zip the entire tree for storage.

Comment 3

[timeless]

#6  0x28173996 in gc_root_marker (table=0x80d1020, hdr=0x8d47784, num=553, 
arg=0x90bdc00)
    at /home/timeless/mozilla/js/src/jsgc.c:955
955             GC_MARK(cx, JSVAL_TO_GCTHING(v), rhe->name ? rhe->name : 
"root", NULL);
(gdb) p rhe
$1 = (JSGCRootHashEntry *) 0x8d47784
(gdb) p rhe->name
$2 = 0x28942740 "XPCWrappedNative::mFlatJSObject"

Is that what you're looking for?

Comment 4

[Brendan Eich [:brendan]]

Cc'ing jband and myself -- could this be an XPConnect bug?

/be

Comment 5

[Phil Schwartau]

Changing component, QA to XPConnect. 

timeless: if you still have that 97-frame stack trace, could you 
attach it to this bug as a text file? Thanks - 

Comment 6

[John Bandhauer]

Yes. It most likely is an xpconnect problem. But I don't know exactly why. I
have theories. The refcount based root and unroot is not interlocked with gc in
a safe enough way to really allow fully safe multi-threaded access. Though,
almost all wrapped natives in the system are *supposed* to be accessed only on
the main thread. We are going to have to attack the scheme mentioned in bug
112152 sometime - get rid of root/unroot, do explicit marking, explicitly scan
for dying JSObjects rather than wait through finilization, and interlock between
addref/release and that scanning phase. If we do all that for wrapped natives
and wrapped JSObject then we should be able to cut down on root/unroot overhead
and also make the refcounting/gc bridge truly safe.

FWIW, I could not get this to fail or crash on Win2000. My Linux build actually
worked with the plugin and aborts silently when I mouse over the animation. My
underpowered Linux box is not currently setup to run mozilla under gdb (lack of
memory with default settings). So, I have not managed to see this live in a
debugger yet.

Comment 7

[timeless]

Attachment: freebsd stack crawl

Comment 8

[David Bradley]

I'm seeing very few of the js_Mark crashes in the trunk. More occur in the Gecko
1.0 release. I'm not sure if this is a result of the check-in to the trunk in
bug 139243 that removes the rooting logic of wrapped natives or just the
difference in the number of users running trunk vs branch.

Comment 9

[David Bradley]

I think this was just another flavor of bug 180182. I see no Talkback incidents
on the trunk after this patch was checked in. And incidents are occuring on 1.2
which doesn't have this patch. Don't want to dupe just yet, will keep an eye on it.

Comment 10

[R.K.Aa.]

Tested it on an official build now and couldn't make this crash anymore. WFM.
Perhaps not worth spending more time on; it won't load in gcc-3.2 builds:

LoadPlugin: failed to initialize shared library
/home/dark/.netscape/plugins/cult3d/libcult3dplugin.so
[/home/dark/.netscape/plugins/cult3d/libcult3dplugin.so: undefined symbol:
good__C3ios]

Comment 11

[Pieter Wolters]

Cult3d worked for  (Mandrake 9.0) in this build (1.3)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

But not anymore in this build (1.4)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401. it gave the
errors as reported in Comment #10

PW

Comment 12

[timeless]

fwiw comment 10 is bug 184854

*** This bug has been marked as a duplicate of 180182 ***

Comment 13

[Phil Schwartau]

I'll go ahead and mark this one verified, but timeless: can you 
say a bit more on why this is a duplicate of bug 180182?

I don't see any relation between the stack traces, but you 
understand this much better than I do; thanks -