Closed Bug 1202008 Opened 10 years ago Closed 10 years ago

crash in js::Lambda(JSContext*, JS::Handle<T>, JS::Handle<T>)

Categories

(Core :: General, defect)

41 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1177898
Tracking Status
firefox41 --- affected

People

(Reporter: philipp, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-8508c6cb-9c27-4044-8ed7-f92d42150902. ============================================================= Crashing Thread Frame Module Signature Source 0 xul.dll js::Lambda(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>) js/src/vm/Interpreter.cpp 1 xul.dll Interpret js/src/vm/Interpreter.cpp 2 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 3 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 4 xul.dll js::fun_call(JSContext*, unsigned int, JS::Value*) js/src/jsfun.cpp 5 @0x3b23dc8 6 @0x122c240f 7 @0x36a1092f 8 xul.dll js::jit::EnterBaselineMethod(JSContext*, js::RunState&) js/src/jit/BaselineJIT.cpp 9 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 10 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 11 xul.dll js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 12 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp 13 @0x36a141fe 14 @0x313e2a37 15 @0x36a1092f 16 xul.dll EnterBaseline js/src/jit/BaselineJIT.cpp 17 xul.dll js::jit::EnterBaselineAtBranch(JSContext*, js::InterpreterFrame*, unsigned char*) js/src/jit/BaselineJIT.cpp 18 xul.dll Interpret js/src/vm/Interpreter.cpp this windows crash seems to get more prevalent in firefox 41 beta than compared to before. it's currently the #11 most frequent browser crash amounting for ~0.8% of crashes in 41.0b6 (excluding shutdownhangs).
Thanks for pointing this out. js::Lambda is more or less a wrapper around CloneFunctionObjectIfNotSingleton. Given the prevalence of 0x3c addresses, I'm going to assume that CloneFunctionObjectIfNotSingleton got inlined here, making this a variant of bug 1177898, which should be fixed in the next beta.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.