Closed
Bug 1238575
Opened 9 years ago
Closed 9 years ago
Crash [@ js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup] or Assertion failure: ((size_t)atom & 0x7) == 0, at jsfriendapi.h:2533 with OOM
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla46
Tracking | Status | |
---|---|---|
firefox46 | --- | fixed |
People
(Reporter: decoder, Assigned: jonco)
References
(Blocks 1 open bug)
Details
(4 keywords, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(1 file)
4.50 KB,
patch
|
terrence
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision 6020a4cb41a7 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-check-range-analysis):
oomAfterAllocations(5)
gcslice(11);
evalInWorker("}");
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff44ff700 (LWP 43265)]
js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup (this=0xe5e5e5e5e5e5e5e5, l=..., keyHash=367279502, collisionBit=0) at js/src/debug64/dist/include/js/HashTable.h:1291
#0 js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup (this=0xe5e5e5e5e5e5e5e5, l=..., keyHash=367279502, collisionBit=0) at js/src/debug64/dist/include/js/HashTable.h:1291
#1 0x000000000053ba99 in readonlyThreadsafeLookup (l=..., this=0xe5e5e5e5e5e5e5e5) at js/src/debug64/dist/include/js/HashTable.h:1627
#2 readonlyThreadsafeLookup (l=..., this=0xe5e5e5e5e5e5e5e5) at js/src/debug64/dist/include/js/HashTable.h:345
#3 readonlyThreadsafeLookup (l=..., this=<optimized out>) at js/src/jsatom.cpp:98
#4 AtomizeAndCopyChars<unsigned char> (pin=js::DoNotPinAtom, length=14, tbchars=0xe8dae6 "eventsMeasured", cx=0x7ffff454a800) at js/src/jsatom.cpp:317
#5 js::Atomize (cx=cx@entry=0x7ffff454a800, bytes=bytes@entry=0xe8dae6 "eventsMeasured", length=14, pin=pin@entry=js::DoNotPinAtom) at js/src/jsatom.cpp:409
#6 0x00000000008bcc19 in PropertySpecNameToId (cx=cx@entry=0x7ffff454a800, name=0xe8dae6 "eventsMeasured", id=id@entry=..., pin=pin@entry=js::DoNotPinAtom) at js/src/jsapi.cpp:3135
#7 0x00000000008d28ab in JS_DefineProperties (cx=cx@entry=0x7ffff454a800, obj=..., obj@entry=..., ps=0x1b8a510 <pm_props+528>, ps@entry=0x1b8a300 <pm_props>) at js/src/jsapi.cpp:3160
#8 0x0000000000a21340 in js::DefinePropertiesAndFunctions (cx=cx@entry=0x7ffff454a800, obj=..., obj@entry=..., ps=ps@entry=0x1b8a300 <pm_props>, fs=fs@entry=0x1b8a580 <pm_fns>) at js/src/vm/GlobalObject.cpp:525
#9 0x0000000000971470 in DefineConstructorAndPrototype (ctorKind=js::gc::FIRST, ctorp=0x0, static_fs=0x0, static_ps=0x0, fs=0x1b8a580 <pm_fns>, ps=0x1b8a300 <pm_props>, nargs=<optimized out>, constructor=<optimized out>, clasp=0xaa8bfd <PR_GetCurrentThread()+29>, protoProto=..., atom=..., key=JSProto_Null, obj=..., cx=0x7ffff454a800) at js/src/jsobj.cpp:1820
#10 js::InitClass (cx=cx@entry=0x7ffff454a800, obj=..., obj@entry=..., protoProto_=..., protoProto_@entry=..., clasp=clasp@entry=0x1b8a0e0 <pm_class>, constructor=constructor@entry=0x98ff90 <pm_construct(JSContext*, unsigned int, JS::Value*)>, nargs=nargs@entry=1, ps=ps@entry=0x1b8a300 <pm_props>, fs=fs@entry=0x1b8a580 <pm_fns>, static_ps=static_ps@entry=0x0, static_fs=static_fs@entry=0x0, ctorp=ctorp@entry=0x0, ctorKind=ctorKind@entry=js::gc::FIRST) at js/src/jsobj.cpp:1882
#11 0x00000000008c3c82 in JS_InitClass (cx=cx@entry=0x7ffff454a800, obj=obj@entry=..., parent_proto=parent_proto@entry=..., clasp=clasp@entry=0x1b8a0e0 <pm_class>, constructor=constructor@entry=0x98ff90 <pm_construct(JSContext*, unsigned int, JS::Value*)>, nargs=nargs@entry=1, ps=ps@entry=0x1b8a300 <pm_props>, fs=fs@entry=0x1b8a580 <pm_fns>, static_ps=static_ps@entry=0x0, static_fs=static_fs@entry=0x0) at js/src/jsapi.cpp:1708
#12 0x000000000098fe84 in JS::RegisterPerfMeasurement (cx=cx@entry=0x7ffff454a800, globalArg=..., globalArg@entry=...) at js/src/perf/jsperf.cpp:246
#13 0x000000000048a912 in NewGlobalObject (cx=cx@entry=0x7ffff454a800, options=..., principals=principals@entry=0x0) at js/src/shell/js.cpp:6078
#14 0x0000000000492f4e in WorkerMain (arg=0x7ffff699a520) at js/src/shell/js.cpp:2765
#15 0x0000000000aa82f1 in nspr::Thread::ThreadRoutine (arg=0x7ffff699a540) at js/src/vm/PosixNSPR.cpp:45
#16 0x00007ffff7bc4182 in start_thread (arg=0x7ffff44ff700) at pthread_create.c:312
#17 0x00007ffff6cb3fbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
rax 0x15e43d8f 367279503
rbx 0x7ffff44fe590 140737292264848
rcx 0x0 0
rdx 0x15e43d8e 367279502
rsi 0x7ffff44fe5e0 140737292264928
rdi 0xe5e5e5e5e5e5e5e5 -1880844493789993499
rbp 0x7ffff44fe550 140737292264784
rsp 0x7ffff44fe4f0 140737292264688
r8 0x7ffff44fe478 140737292264568
r9 0x0 0
r10 0x1 1
r11 0x31c48c1f 834964511
r12 0xe8dae6 15260390
r13 0xe 14
r14 0xe5e5e5e5e5e5e5e5 -1880844493789993499
r15 0x15e43d8e 367279502
rip 0x53cfd2 <js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(js::AtomHasher::Lookup const&, unsigned int, unsigned int) const+50>
=> 0x53cfd2 <js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(js::AtomHasher::Lookup const&, unsigned int, unsigned int) const+50>: mov (%rdi),%rbx
0x53cfd5 <js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::lookup(js::AtomHasher::Lookup const&, unsigned int, unsigned int) const+53>: mov %rdi,%r13
The crash address indicates some form of use-after-free and the random assertion popping up inbetween also looks like memory corruption. Marking s-s.
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•9 years ago
|
||
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===
The "bad" changeset has the timestamp "20150917010649" and the hash "13046b64bc825bd87963c5c69dd60550622e26f8".
The "good" changeset has the timestamp "20150921151939" and the hash "bfb0223e309336ced37770e5ce235bc68caf4acd".
Likely fix window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=13046b64bc825bd87963c5c69dd60550622e26f8&tochange=bfb0223e309336ced37770e5ce235bc68caf4acd
autoBisect probably got confused at some point, so the bisection window is likely not reliable.
Jon, do you think you could take a look?
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 4•9 years ago
|
||
The problem here is that in the shell implementation, if we fail to add a worker thread to the list of workers we don't join on the thread. That leads to the situation where we destroy the main runtime while there still a worker runtime that has it as its parent runtime. This child runtime tries to access some freed memory and crashes.
I fixed the issue in the shell and added a count of child runtimes in debug builds so we can assert that there are no more children depending on us when we destroy the parent.
Attachment #8706975 -
Flags: review?(terrence)
Comment 5•9 years ago
|
||
Comment on attachment 8706975 [details] [diff] [review]
bug1238575-child-runtimes
Review of attachment 8706975 [details] [diff] [review]:
-----------------------------------------------------------------
::: js/src/vm/Runtime.cpp
@@ +245,5 @@
>
> +#ifdef DEBUG
> + if (parentRuntime)
> + parentRuntime->childRuntimeCount++;
> +#endif
This is a lot of #ifdef DEBUG. Would it perhaps be clearer to add an AutoTraceChildRuntimeCount or somesuch? I'm fine either way.
Attachment #8706975 -
Flags: review?(terrence) → review+
Assignee | ||
Comment 6•9 years ago
|
||
(In reply to Terrence Cole [:terrence] from comment #5)
I tried wrapping the Atomic<> in DebugOnly<> but found I couldn't get the == 0 test to compile.
Yes, an RAII class looks like it would do the trick.
Assignee | ||
Comment 7•9 years ago
|
||
Unmarking s-s because this is shell only.
Group: javascript-core-security
Comment 9•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in
before you can comment on or make changes to this bug.
Description
•