235046 - assert calling jsd_Lock on main thread while another thread is in GC

Status: RESOLVED INCOMPLETE

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

Description

[timeless]

JS_Assert (debug:abort()) running threaded javascript test in xpcshell.

same steps and expected results as in bug 235038

note that I've crashed 3 out of 4 runs today, I lost one set of stacks, I'm
really sorry.

actual results: 
...
--- loop number 7722
  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 8. 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.03 seconds.
--- loop number 7723
  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
Assertion failure: (! lock->count && ! lock->owner) || (lock->count &&
lock->owner), at r:/mozilla/j
s/jsd/jsd_lock.c:106
Assertion failure: (! lock->count && ! lock->owner) || (lock->count &&
lock->owner), at r:/mozilla/j
s/jsd/jsd_lock.c:106
<assert> 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 asserting main thread (many frames dropped):
JS_Assert
ASSERT_VALID_LOCK
jsd_Lock
jsd_FunctionCallHook
js_Invoke
nsXPCConstructor::Construct

The garbage collecting thread (many frames dropped):
PR_WaitCondVar
js_GC
js_ForceGC
js_DestroyContext
_PR_CleanupThread
_PR_NativeRunThread

So far the common piece of my crashes is garbage collection, so I suppose I'd
like to lean toward blaming spidermonkey.

Comment 1

[timeless]

Attachment: stacks for all threads in crashed xpcshell

Comment 2

[timeless]

Ok, i just hit a second version of what i'm hoping is this assert, the stacks
are different but the jsd_Lock bit is at least the same.

Here's the lock object from jsd_Lock in the original assertion:
-	lock	0x00f46b90 {owner=0x00000000 lock=0x00f46bd0 count=0 ...}	JSDStaticLock *
	owner	0x00000000	void *
	lock	0x00f46bd0	PRLock *
	count	0	int
	sig	4300	unsigned short

void ASSERT_VALID_LOCK(JSDStaticLock* lock)
{
    JS_ASSERT(lock);
    JS_ASSERT(lock->lock);
    JS_ASSERT(lock->count >= 0);
    JS_ASSERT((! lock->count && ! lock->owner) || (lock->count && lock->owner));
    JS_ASSERT(lock->sig == (uint16) JSD_LOCK_SIG);
}    

I'm wondering if one of the lock members is changing in another thread (since
there's no lock protecting these members).

Comment 3

[timeless]

note that i hit it using the original threads.js (i.e. skipping step 3 of bug
23508 comment 0). also note that the testcase can run to completion (and for the
original threads.js flavor it did 2 out of 3 times).

Comment 4

[Philip Helger]

I have the same problem in a multithreaded environment.
Since JSD_LOCK works on a global lock object
(see http://lxr.mozilla.org/mozilla1.8/source/js/jsd/jsd.h#784)
it should work out for you to comment the specified line
http://lxr.mozilla.org/mozilla1.8/source/js/jsd/jsd_lock.c#106

I can almost always reproduce the bug if HyperThreading is enabled.
This is because the ASSERT_VALID_LOCK function is called while
another thread is in jsd_unlock just between decrementing
lock->count but before setting lock->owner to NULL.
hth

Comment 5

[BMO Automation]

Component is obsolete so resolving bugs as INCOMPLETE