430290 - actionmonkey-tamarin: assertions when doing allocations from a postcollect hook

Status: VERIFIED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Benjamin Smedberg]

I'm trying to do "real work" == allocations from a postcollect hook:

http://hg.mozilla.org/users/bsmedberg_mozilla.com/xpcomgc-patches/index.cgi/file/d03021664afc/http-connection-reclamation

This is causing the following assertions in MMgc:
"Assertion failed: \"((!m_gcRunning))\" (\"/builds/xpcomgc/src/js/tamarin/MMgc/GC.cpp\":645)"
"Assertion failed: \"((GCThread::GetCurrentThread()->IsInActiveRequest()))\" (\"/builds/xpcomgc/src/js/tamarin/MMgc/GC.cpp\":655)"

Comment 1

[Benjamin Smedberg]

Perhaps more concerningly, this also causes a deadlock:

(gdb) thread 1
(gdb) bt 10
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x003ea119 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0x003e58dd in _L_lock_839 () from /lib/libpthread.so.0
#3  0x003e580f in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0xf3c05f39 in PR_Lock (lock=0x80bf97c) at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:206
#5  0xf3c06c4d in PR_EnterMonitor (mon=0x80bf978) at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:531
#6  0xf7de0b38 in RequestSafeEnterMonitor (monitor=0x80bf978) at ../../../../dist/include/xpcom/nsAutoLock.h:138
#7  0xf7e1b69d in nsAutoMonitor::nsAutoMonitor () at ../../../src/xpcom/io/nsStorageStream.cpp:161
#8  0xf7e462cb in nsEventQueue::PutEvent (this=0xf2bdd1b8, runnable=0xf2c47948) at ../../../src/xpcom/threads/nsEventQueue.cpp:109
#9  0xf7e47aae in nsThread::nsChainedEventQueue::PutEvent (this=0xf2bdd1b0, event=0xf2c47948)
    at ../../../src/xpcom/threads/nsThread.cpp:660
(More stack frames follow...)

(gdb) thread 2
(gdb) bt 12
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x003e75d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xf3c06787 in PR_WaitCondVar (cvar=0x805acb0, timeout=4294967295) at ../../../../../src/nsprpub/pr/src/pthreads/ptsynch.c:405
#3  0xf7edeb11 in MMgc::GCCondition::Wait (this=0x8059b7c) at ../../../src/js/tamarin/MMgc/GCThreads.h:153
#4  0xf7edeb93 in MMgc::GC::WaitForGCDone (this=0x80597c8) at ../../../src/js/tamarin/MMgc/GC.h:1666
#5  0xf7ed2d25 in JS_BeginRequest (cx=0x80bfcc0) at ../../../src/js/src/jsapi.cpp:854
#6  0xf7ed2e10 in JS_ResumeRequest (cx=0x80bfcc0, saveDepth=0) at ../../../src/js/src/jsapi.cpp:988
#7  0xf7e51201 in nsAutoSuspendRequest::~nsAutoSuspendRequest () at ../../../../src/xpcom/proxy/src/nsProxyEvent.cpp:119
#8  0xf7de0b43 in RequestSafeEnterMonitor (monitor=0x80bf978) at ../../../../dist/include/xpcom/nsAutoLock.h:138
#9  0xf7e1b69d in nsAutoMonitor::nsAutoMonitor () at ../../../src/xpcom/io/nsStorageStream.cpp:161
#10 0xf7e463fe in nsEventQueue::GetEvent (this=0xf2bdd1b8, mayWait=0, result=0xf26501b0)
    at ../../../src/xpcom/threads/nsEventQueue.cpp:74
#11 0xf7e4a170 in nsThread::nsChainedEventQueue::GetEvent (this=0xf2bdd1b0, mayWait=0, event=0xf26501b0)
    at ../../../src/xpcom/threads/nsThread.h:112
(More stack frames follow...)

This means that the postcollect hook (or the new hook which I need) needs to run after the other threads have been unblocked/restarted.

Comment 2

[Benjamin Smedberg]

I updated http://wiki.mozilla.org/GC_API with what I believe are the requirements for this hook. I left the separate postsweep hook alone, assuming that it needs to run before other threads are restarted.

Comment 3

[Jason Orendorff [:jorendorff]]

OK.  The JSGC_END callback does what you want.

http://developer.mozilla.org/en/docs/JS_SetGCCallback

No equivalent callback is exposed via MMgc::GCCallback, though; jsgc.cpp cheats to arrange for JSGC_END to happen as desired.  It will be hard to fix this before Thursday or so.  Other than hacking the JSGCCallback, I don't see an easy workaround.

Comment 4

[Jason Orendorff [:jorendorff]]

Mass-WONTFIXing ActionMonkey bugs.