951056 - Assertion failure: !aGCThing, at xpcom/base/CycleCollectedJSRuntime.cpp:828

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Douglas Crosher [:dougc]]

Visiting the URL causes an asm.js jor1k cpu emulator to start and if left alone it systematically crashes on an assertion failure.

Backtrace of crashing thread:
#0  0x00007f61c686f4fd in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f61c686f3a1 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x00007f61c204d568 in ah_crap_handler (signum=11) at src/toolkit/xre/nsSigHandlers.cpp:88
#3  0x00007f61c2055d14 in nsProfileLock::FatalSignalHandler (signo=11, info=<optimized out>, context=<optimized out>) at src/profile/dirserviceprovider/src/nsProfileLock.cpp:190
#4  <signal handler called>
#5  AssertNoGcThing (aGCThing=<optimized out>, aName=<optimized out>, aClosure=<optimized out>) at src/xpcom/base/CycleCollectedJSRuntime.cpp:828
#6  0x00007f61c02bd93b in mozilla::CycleCollectedJSRuntime::AssertNoObjectsToTrace (this=<optimized out>, aPossibleJSHolder=0x7f6186217aa0) at src/xpcom/base/CycleCollectedJSRuntime.cpp:836
#7  0x00007f61c02c0d05 in nsCycleCollector::CollectWhite (this=0x7f618f527000) at src/xpcom/base/nsCycleCollector.cpp:2574
#8  0x00007f61c02c18d2 in nsCycleCollector::Collect (this=0x7f618f527000, aCCType=ManualCC, aBudget=..., aManualListener=0x0) at src/xpcom/base/nsCycleCollector.cpp:2873
#9  0x00007f61c02c28b2 in nsCycleCollector_collect (aManualListener=0x0) at src/xpcom/base/nsCycleCollector.cpp:3395
#10 0x00007f61c29929ee in Collect (rt=0x7f618f530000, incremental=false, budget=0, gckind=js::GC_SHRINK, reason=JS::gcreason::DOM_WORKER) at src/js/src/jsgc.cpp:4933
#11 0x00007f61c1454ece in mozilla::dom::workers::WorkerPrivate::GarbageCollectInternal (this=<optimized out>, aCx=<optimized out>, aShrinking=<optimized out>, aCollectChildren=<optimized out>)
    at src/dom/workers/WorkerPrivate.cpp:5252
#12 0x00007f61c145a486 in (anonymous namespace)::GarbageCollectRunnable::WorkerRun (this=<optimized out>, aCx=0x7f61c6b67a00 <_IO_stdfile_2_lock>, aWorkerPrivate=0x7f61c6b661a0 <_IO_2_1_stderr_>)
    at src/dom/workers/WorkerPrivate.cpp:1578
#13 0x00007f61c144ef2e in mozilla::dom::workers::WorkerRunnable::Run (this=0x7f61a0a928e0) at src/dom/workers/WorkerPrivate.cpp:1878
#14 0x00007f61c1450ce8 in mozilla::dom::workers::WorkerPrivate::DoRunLoop (this=0x7f618d679000, aCx=0x7f6190bae6c0) at src/dom/workers/WorkerPrivate.cpp:3852
#15 0x00007f61c1442737 in (anonymous namespace)::WorkerThreadRunnable::Run (this=<optimized out>) at src/dom/workers/RuntimeService.cpp:1010
#16 0x00007f61c03269f7 in nsThread::ProcessNextEvent (this=0x7f6191683080, mayWait=false, result=0x7f61871fbd0f) at src/xpcom/threads/nsThread.cpp:634
#17 0x00007f61c02a2298 in NS_ProcessNextEvent (thread=<optimized out>, mayWait=false) at src/xpcom/glue/nsThreadUtils.cpp:263
#18 0x00007f61c06184ed in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7f6193f2fe80, aDelegate=0x7f6190be8900) at src/ipc/glue/MessagePump.cpp:301
#19 0x00007f61c05d6f25 in MessageLoop::RunInternal (this=0x7f6190be8900) at src/ipc/chromium/src/base/message_loop.cc:226
#20 0x00007f61c05d6e55 in MessageLoop::Run (this=0x7f6190be8900) at src/ipc/chromium/src/base/message_loop.cc:193
#21 0x00007f61c032595c in nsThread::ThreadFunc (arg=0x7f6191683080) at src/xpcom/threads/nsThread.cpp:258
#22 0x00007f61c63eb38d in _pt_root (arg=0x7f6191381be0) at src/nsprpub/pr/src/pthreads/ptthread.c:205
#23 0x00007f61c7799d15 in start_thread (arg=0x7f61871fc700) at pthread_create.c:308
#24 0x00007f61c68a653d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114

Comment 1

[Douglas Crosher [:dougc]]

Can not reproduce this on the official builds.  Seeing this on a debug build of m-c Linux 64 bit, built with clang.  Shall explore some other local build options.

Comment 2

[Douglas Crosher [:dougc]]

Also reproducible on a debug build of m-c Linux 32 bit built with gcc.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This looks like more of a cycle collector issue.

Comment 4

[Andrew McCreight [:mccr8]]

Do you have a test case for this?  There's a known issue with XHR on workers that produces this assert.  The problem is that some Unlink method isn't clearing the JS pointers that are traced.

Comment 5

[Douglas Crosher [:dougc]]

(In reply to Andrew McCreight [:mccr8] from comment #4)
> Do you have a test case for this?  There's a known issue with XHR on workers
> that produces this assert.  The problem is that some Unlink method isn't
> clearing the JS pointers that are traced.

Sorry, no reduced test case, just the above URL which reliably reproduces the crash.

The code does use XHR to load resources so perhaps this is a known issue.  Can this bug be kept open until the XHR issue is resolved and the above URL is re-tested.