Closed
Bug 627698
Opened 13 years ago
Closed 12 years ago
Possible race on js::workers::Worker::current
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jseward, Unassigned)
Details
Attachments
(1 file)
10.00 KB,
application/octet-stream
|
Details |
Maybe some other synchronisation makes this safe? Unclear to me whether or not this is a false positive. Possible data race during read of size 8 at 0x215e7fe0 by thread #3 at 0x40ED3A: js::workers::Worker::jsTraceWorker(JSTracer*, JSObject*) (jsworkers.cpp:682) by 0x486B4B: js_TraceObject(JSTracer*, JSObject*) (jsobj.cpp:6426) by 0x41CEC7: js::gc::MarkChildren(JSTracer*, JSObject*) (jsgcinlines. by 0x41F585: JS_CallTracer (jsgcinlines.h:347) by 0x40EEEF: js::workers::ThreadPool::jsTraceThreadPool (jsworkers.cpp:1235) by 0x486B4B: js_TraceObject(JSTracer*, JSObject*) (jsobj.cpp:6426) by 0x41CEC7: js::gc::MarkChildren(JSTracer*, JSObject*) (jsgcinlines. by 0x41F585: JS_CallTracer (jsgcinlines.h:347) by 0x40B89D: js::workers::MainQueue::trace(JSTracer*) (jsworkers.cpp: by 0x40EC80: js::workers::Worker::jsTraceWorker(JSTracer*, JSObject*) by 0x486B4B: js_TraceObject(JSTracer*, JSObject*) (jsobj.cpp:6426) by 0x4869D7: js::gc::MarkChildren(JSTracer*, JSObject*) (jsgcinlines. // unclear if Worker::lock is held here This conflicts with a previous write of size 8 by thread #4 at 0x40D5CE: js::workers::Worker::processOneEvent() (jsworkers.cpp:1151) by 0x40D9A9: js::workers::WorkerQueue::work() (jsworkers.cpp:1006) by 0x40FF8D: js::workers::ThreadPool::start(void*) (jsworkers.cpp:461) by 0x5077EC2: _pt_root (ptthread.c:189) by 0x4C2CBE7: mythread_wrapper (hg_intercepts.c:221) by 0x4E369C9: start_thread (pthread_create.c:300) by 0x5D2370C: clone (clone.S:112) // this clearly holds Worker::lock (see jsworkers.cpp:1150) Address 0x215e7fe0 is 208 bytes inside a block of size 224 alloc'd at 0x4C2841A: operator new(unsigned long) (vg_replace_malloc.c:2 by 0x40C249: js::workers::Worker::create (jsworkers.cpp:1075) by 0x40FE13: js::workers::Worker::jsConstruct(JSContext*, unsign by 0x1440FD0F: ??? by 0x524008: js::ExecuteTree(JSContext*, js::TreeFragment*, unsi by 0x541866: js::RecordLoopEdge(JSContext*, unsigned int&) (jstr by 0x5419D6: js::MonitorLoopEdge(JSContext*, unsigned int&) (jst by 0x5BAFD5: js::Interpret(JSContext*, JSStackFrame*, unsigned i by 0x535BFB: js::RecordTracePoint(JSContext*, unsigned int&, boo by 0x535FA0: js::MonitorTracePoint(JSContext*, unsigned int&, bo
Reporter | ||
Comment 1•13 years ago
|
||
Testcase -- modified version of PaulB's 619595 test. cd js/src # ./R64 holds 64-bit opt shell build # and using a NSPR from the same tree: LD_LIBRARY_PATH=/space2/sewardj/MOZ/MC-20-10-2011-HG/ff-opt/dist/sdk/lib \ vTRUNK --conflict-cache-size=10000000 --smc-check=all \ --tool=helgrind \ ./R64/js -j -m -p workers2.js This requires ~5GB of memory and 10-20 CPU minutes. Report appears near end of run. Also requires a properly marked up NSPR and SpiderMonkey, else helgrind reports zillions of false races.
Comment 2•12 years ago
|
||
See bug 771281.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•