Closed Bug 1285227 Opened 3 years ago Closed 3 years ago

Crash [@ TryPreserveReflector] or Crash [@ __interceptor_pthread_create] or Assertion failure: cx->runtime()->preserveWrapperCallback, at builtin/WeakMapObject.cpp:119 with evalInWorker

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: decoder, Assigned: jandem)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [jsbugmon:update])

Crash Data

Attachments

(1 file, 1 obsolete file)

The following testcase crashes on mozilla-central revision 4764b9f8e6d4 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug --enable-optimize, run with --fuzzing-safe):

evalInWorker(`
    (new WeakMap).set(FakeDOMObject.prototype, this)
`);


Backtrace:

 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2fff700 (LWP 18656)]
0x0000000000000000 in ?? ()
#0  0x0000000000000000 in ?? ()
#1  0x0000000000a49bec in TryPreserveReflector (cx=0x7ffff69ae000, obj=...) at js/src/builtin/WeakMapObject.cpp:120
#2  0x0000000000a57499 in SetWeakMapEntryInternal (value=..., key=..., mapObj=..., cx=0x7ffff69ae000) at js/src/builtin/WeakMapObject.cpp:147
#3  WeakMap_set_impl (args=..., cx=0x7ffff69ae000) at js/src/builtin/WeakMapObject.cpp:182
#4  JS::CallNonGenericMethod<&(IsWeakMap(JS::Handle<JS::Value>)), &(WeakMap_set_impl(JSContext*, JS::CallArgs const&))> (args=..., cx=0x7ffff69ae000) at /srv/jenkins/jobs/mozilla-central-build-jsshell/workspace/arch/64/compiler/gcc/sanitizer/none/type/opt/dist/include/js/CallNonGenericMethod.h:100
#5  js::WeakMap_set (cx=0x7ffff69ae000, argc=<optimized out>, vp=<optimized out>) at js/src/builtin/WeakMapObject.cpp:192
#6  0x00000000008f8e33 in js::CallJSNative (args=..., native=<optimized out>, cx=0x7ffff69ae000) at js/src/jscntxtinlines.h:232
#7  js::InternalCallOrConstruct (cx=0x7ffff69ae000, args=..., construct=<optimized out>) at js/src/vm/Interpreter.cpp:453
#8  0x00000000008f410c in js::CallFromStack (args=..., cx=<optimized out>) at js/src/vm/Interpreter.cpp:504
#9  Interpret (cx=0x7ffff69ae000, state=...) at js/src/vm/Interpreter.cpp:2873
#10 0x00000000008f8a10 in js::RunScript (cx=cx@entry=0x7ffff69ae000, state=...) at js/src/vm/Interpreter.cpp:399
#11 0x00000000008faab8 in js::ExecuteKernel (result=0x7ffff2ffedc0, evalInFrame=..., newTargetValue=..., scopeChainArg=..., script=..., cx=0x7ffff69ae000) at js/src/vm/Interpreter.cpp:679
#12 js::Execute (cx=cx@entry=0x7ffff69ae000, script=..., script@entry=..., scopeChainArg=..., rval=0x7ffff2ffedc0) at js/src/vm/Interpreter.cpp:712
#13 0x0000000000746594 in ExecuteScript (cx=cx@entry=0x7ffff69ae000, scope=..., scope@entry=..., script=script@entry=..., rval=rval@entry=0x7ffff2ffedc0) at js/src/jsapi.cpp:4309
#14 0x000000000074c7a8 in JS_ExecuteScript (cx=cx@entry=0x7ffff69ae000, scriptArg=scriptArg@entry=..., rval=rval@entry=...) at js/src/jsapi.cpp:4335
#15 0x0000000000452928 in WorkerMain (arg=0x7ffff69aa2e0) at js/src/shell/js.cpp:2990
#16 0x0000000000907e29 in nspr::Thread::ThreadRoutine (arg=0x7ffff69aa300) at js/src/vm/PosixNSPR.cpp:45
#17 0x00007ffff7bc16fa in start_thread (arg=0x7ffff2fff700) at pthread_create.c:333
#18 0x00007ffff6c38b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
rax	0x7ffff2b04160	140737265025376
rbx	0x7ffff69ae000	140737330733056
rcx	0x7ffff695fe08	140737330413064
rdx	0x210	528
rsi	0x7ffff2b04160	140737265025376
rdi	0x7ffff69ae000	140737330733056
rbp	0x7ffff69ae000	140737330733056
rsp	0x7ffff2ffe378	140737270244216
r8	0x0	0
r9	0xa	10
r10	0x7ffff330d090	140737273450640
r11	0xfffdffffffffffff	-562949953421313
r12	0x7ffff2b070f8	140737265037560
r13	0x7ffff69ae1c8	140737330733512
r14	0x7ffffffff000	140737488351232
r15	0x7ffff2ffe640	140737270244928
rip	0x0	0
=> 0x0:
This seems to have existed since m-c rev dc4b163f7db7 (early Nov 2014). Setting needinfo? from Andrew, who previously fixed a similar issue in bug 829798.

(Please feel free to move the needinfo? forward if necessary)
Flags: needinfo?(continuation)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
I think somebody just needs to pass a similar DummyPreserveWrapperCallback thing to a js::SetPreserveWrapperCallback call, wherever the JS shell sets up the runtime used for whatever evalInWorker is. I don't know anything about how evalInWorker works.
Flags: needinfo?(continuation)
Jan, do you know? (Just passing the baton, bug 1240544 comment 1 mentioned you touched EvalInWorker earlier this year)
Flags: needinfo?(jdemooij)
Attached patch Patch (obsolete) — Splinter Review
What mccr8 said.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)
Attachment #8770446 - Flags: review?(terrence)
Attached patch PatchSplinter Review
Attachment #8770446 - Attachment is obsolete: true
Attachment #8770446 - Flags: review?(terrence)
Attachment #8770448 - Flags: review?(terrence)
Attachment #8770448 - Flags: review?(terrence) → review+
Pushed by jandemooij@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/14c4da8b9959
Use DummyPreserveWrapperCallback for evalInWorker as well. r=terrence
https://hg.mozilla.org/mozilla-central/rev/14c4da8b9959
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.