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)

Unspecified
Windows
defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox52 --- affected

People

(Reporter: cyu, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
I need to narrow down the test case that triggers the error and get the stack of previous initialization of the SRW lock.
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.

Attachment

General

Created:
Updated:
Size: