235038 - Crash cleaning up javascript thread jsd_DropAtom(JSDContext * jsdc=0x01130118, JSDAtom * atom=0xffffffff)

Status: RESOLVED INVALID

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[timeless]

Crash running threaded javascript test in xpcshell.

steps:
0. use cvs trunk (to get dangerous xpconnect classinfo patch)
1. apply incomplete patch for bug 81879
<http://viper.haque.net/~timeless/81879/81879> which tries to mark some
xpconnect classes as threadsafe
2. apply trivial patch in bug 235035
3. apply this patch (risky):
Index: js/src/xpconnect/tests/js/old/threads.js
===================================================================
RCS file: /cvsroot/mozilla/js/src/xpconnect/tests/js/old/threads.js,v
retrieving revision 1.1
diff -u -r1.1 js/src/xpconnect/tests/js/old/threads.js
--- js/src/xpconnect/tests/js/old/threads.js
+++ js/src/xpconnect/tests/js/old/threads.js
@@ -20,6 +20,6 @@
     // Commented this because I was thinking that the printf impl being called
     // on so many thread might be contributing to some apparent memory
     // corruption cases.
-    // print("  printed from other thread "+this.id+". foo is: "+foo);
+    print("  printed from other thread "+this.id+". foo is: "+foo);
     for(n in this.__parent__) /* print(n) */;
 }
4. run xpcshell from your mozilla source directory (so that the next step will
work, otherwise you'll need to fix up the path)
5. load('js/src/xpconnect/tests/js/old/threads.js')
6. wait

expected results:
lots of ouput ...
--- loop number 9999
  printed from main thread. foo is 0
  printed from other thread 0. foo is: 1
  printed from other thread 1. foo is: 2
  printed from other thread 2. foo is: 3
  printed from other thread 3. foo is: 4
  printed from other thread 4. foo is: 5
  printed from other thread 5. foo is: 6
  printed from other thread 6. foo is: 7
  printed from other thread 7. foo is: 8
  printed from other thread 8. foo is: 9
  printed from main thread. foo is 9
  printed from other thread 9. foo is: 10
  printed from main thread. foo is 10
        Interval = 0.03 seconds.
Average Interval = 0.04 seconds.
js>
(this is real output from a second run of the same xpcshell with the same dlls
and the same js script)

actual results: 
...
--- loop number 7607
  printed from main thread. foo is 0
  printed from other thread 0. foo is: 1
  printed from other thread 1. foo is: 2
  printed from other thread 2. foo is: 3
  printed from other thread 3. foo is: 4
  printed from main thread. foo is 4
  printed from other thread 4. foo is: 5
  printed from other thread 5. foo is: 6
  printed from other thread 6. foo is: 7
  printed from other thread 7. foo is: 8
  printed from other thread 9. foo is: 10
  printed from other thread 8. foo is: 9
  printed from main thread. foo is 9
        Interval = 0.04 seconds.
Average Interval = 0.04 seconds.
--- loop number 7608
  printed from main thread. foo is 0
  printed from other thread 0. foo is: 1
<crash> I'll attach a file containing all of the stacks.

I'm not sure if this is a jsd threadsafe bug, a spidermonkey threadsafe bug,
user error (always possible, after all, i'm the user), or related to any of
steps 0-3. I've run the test script a few times before and don't ever remember
it crashing.

A short view of the crashed stack (many frames dropped):
jsd_DropAtom
js_FinalizeObject
js_GC
js_ForceGC
_PR_CleanupThread

The other threads are in normal run states (many frames dropped):
PR_WaitCondVar
js_AddRootRT
js_AddRoot
js_InitRegExpStatics
js_NewContext
nsThread::Main
_PR_NativeRunThread

Comment 1

[timeless]

Attachment: stacks for all threads in crashed xpcshell

Comment 2

[Brendan Eich [:brendan]]

Why would this be a SpiderMonkey thread-safety bug.  Last I tested, xpcshell
passed xpconnect/tests/js/old/threads.js.

The crash in jsd_DropAtom sounds like a logic bug, maybe a refcounting bug, in
jsd.  What line was the crash at?  What were the contents of live variables?

/be

Comment 3

[timeless]

The stack trace has line numbers, but here's the function 
jsd_DropAtom(JSDContext* jsdc, JSDAtom* atom)
{
    JSD_LOCK_ATOMS(jsdc);
    if(! --atom->refcount) // crash here; atom: 0xffffffff

    {
        JS_HashTableRemove(jsdc->atoms, atom->str);
        free(atom->str);
        free(atom);
    }
    JSD_UNLOCK_ATOMS(jsdc);
}        

Note that the stack trace also lists the variables that were passed in.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
> Crash running threaded javascript test in xpcshell.
> 
> steps:
> 0. use cvs trunk (to get dangerous xpconnect classinfo patch)
> 1. apply incomplete patch for bug 81879
> <http://viper.haque.net/~timeless/81879/81879> which tries to mark some
> xpconnect classes as threadsafe
> 2. apply trivial patch in bug 235035

bug 81879 was duped to bug 280236. and bug 235035 fixed in 2004.

Comment 5

[:Gijs (he/him)]

OK, given comment #4 and the fact that nobody has said anything else for a half a year -> INVALID. Please reopen if you've got more info.