Closed Bug 627698 Opened 13 years ago Closed 12 years ago

Possible race on js::workers::Worker::current

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jseward, Unassigned)

Details

Attachments

(1 file)

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
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.
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.

Attachment

General

Created:
Updated:
Size: