Closed
Bug 1309840
Opened 8 years ago
Closed 8 years ago
[App Verifier] js::ConditionVariable initializes a SRW lock that is already initialized
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
RESOLVED
INVALID
Tracking | Status | |
---|---|---|
firefox52 | --- | affected |
People
(Reporter: cyu, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
2.97 KB,
application/xml
|
Details |
This error is found in running: ./mach mochitest --total-chunks 11 --this-chunk 2 App verifier reports that the SRW lock used in js::ConditionVariable is already initialized. Stack trace of the error: vfbasics!+7ff8e227caa2 ( @ 0) xul!js::ConditionVariable::ConditionVariable+18 (e:\hg\mozilla-central\js\src\threading\windows\conditionvariable.cpp @ 338) xul!js::gc::GCRuntime::GCRuntime+529 (e:\hg\mozilla-central\js\src\jsgc.cpp @ 875) xul!JSRuntime::JSRuntime+2dd (e:\hg\mozilla-central\js\src\vm\runtime.cpp @ 191) xul!JSContext::JSContext+8d (e:\hg\mozilla-central\js\src\jscntxt.cpp @ 915) xul!js::NewContext+31 (e:\hg\mozilla-central\js\src\jscntxt.cpp @ 108) xul!mozilla::CycleCollectedJSContext::Initialize+5b (e:\hg\mozilla-central\xpcom\base\cyclecollectedjscontext.cpp @ 507) xul!`anonymous namespace'::WorkerThreadPrimaryRunnable::Run+166 (e:\hg\mozilla-central\dom\workers\runtimeservice.cpp @ 2832) xul!nsThread::ProcessNextEvent+2bd (e:\hg\mozilla-central\xpcom\threads\nsthread.cpp @ 1082) xul!NS_ProcessNextEvent+27 (e:\hg\mozilla-central\xpcom\glue\nsthreadutils.cpp @ 290) xul!mozilla::ipc::MessagePumpForNonMainThreads::Run+1f9 (e:\hg\mozilla-central\ipc\glue\messagepump.cpp @ 338) xul!MessageLoop::RunHandler+4b (e:\hg\mozilla-central\ipc\chromium\src\base\message_loop.cc @ 226) xul!MessageLoop::Run+1e (e:\hg\mozilla-central\ipc\chromium\src\base\message_loop.cc @ 206) xul!nsThread::ThreadFunc+102 (e:\hg\mozilla-central\xpcom\threads\nsthread.cpp @ 467) nss3!_PR_NativeRunThread+ee (e:\hg\mozilla-central\nsprpub\pr\src\threads\combined\pruthr.c @ 419) nss3!pr_root+a (e:\hg\mozilla-central\nsprpub\pr\src\md\windows\w95thred.c @ 96) ucrtbase!o__realloc_base+60 ( @ 0) vfbasics!+7ff8e228c729 ( @ 0) KERNEL32!BaseThreadInitThunk+14 ( @ 0) ntdll!RtlUserThreadStart+21 ( @ 0) There might be some js::ConditionVariable that is freed without calling the dtor to destroy the SRW lock. The memory allocator then reuses the address for a new instance.
Reporter | ||
Comment 1•8 years ago
|
||
I need to narrow down the test case that triggers the error and get the stack of previous initialization of the SRW lock.
Reporter | ||
Comment 2•8 years ago
|
||
It turns out that App Verifier takes poisoned variable as initialized because CONDITION_VARIABLE only needs to be initialized, but doesn't need to be destroyed. This error is also reported in jsapi-tests. Turning off poisoning and turning on zeroing in jemalloc resolve the error in jsapi-tests. Close this as invalid.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•