Closed Bug 864037 Opened 12 years ago Closed 12 years ago

Crash in js::InvokeKernel caused by Bug 860145

Categories

(Core :: JavaScript Engine, defect)

23 Branch
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox22 --- unaffected
firefox23 --- unaffected

People

(Reporter: ziga.seilnacht, Unassigned)

References

()

Details

(4 keywords, Whiteboard: [native-crash])

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130420 Firefox/23.0 Build ID: 20130420031010 Steps to reproduce: Open http://qt-project.org/forums/viewthread/15898 Actual results: Nightly crashed. Expected results: Nightly shouldn't crash. This seems to be caused by bug 863349, Windows x86 opt build from here: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b9d35eccad01 works OK, while this one: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=92ed1bf017f0 and builds after it crash.
Blocks: 863349
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ]
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)]
Ever confirmed: true
Hardware: x86_64 → x86
Summary: Crash caused by Bug 863349 → Crash in js::InvokeKernel caused by Bug 863349
It's #3 top crasher in today's build.
Keywords: topcrash
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] [@ js::types::TypeMonitorCallSlow(JSContext*, JSObject*, JS::CallArgs const&, bool) ]
OS: Windows 7 → All
Hardware: x86 → All
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] [@ js::types::TypeMonitorCallSlow(JSContext*, JSObject*, JS::CallArgs const&, bool) ] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] [@ js::types::TypeMonitorCallSlow(JSContext*, JSObject*, JS::CallArgs const&, bool)]
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] [@ js::types::TypeMonitorCallSlow(JSContext*, JSObject*, JS::CallArgs const&, bool)] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*) ] [@ js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)] [@ js::types::TypeMonitorCallSlow(JSContext*, JSObject*, JS::CallArgs const&, bool)] [@ js::types::TypeSet::hasType(js::types::Type) co…
Whiteboard: [native-crash]
Another crashing page is http://qt-project.org/downloads bp-91c8e969-981a-419c-a7ca-962672130421 One of the crashes from loading that page was in [@ JSRope::flatten(JSContext*) ] bp-8eb0023b-c561-4bba-8414-f276c2130421
Bug 863349 causing this is pretty unlikely, and indeed I can reproduce the crash with older builds. Looking for the real culprit now.
Summary: Crash in js::InvokeKernel caused by Bug 863349 → Crash in js::ion::InvokeFunction @ js::InvokeKernel
Looks like bug 860145, I can't reproduce the crash with a build right before that. The page doesn't crash 100% of the time, so you may have to load it two or three times. (And this is why I requested some fuzzing in bug 860145 comment 10...)
Blocks: 860145
No longer blocks: 863349
Summary: Crash in js::ion::InvokeFunction @ js::InvokeKernel → Crash in js::InvokeKernel caused by Bug 860145
Did you see any crashes in js::ArgumentsObject::trace? Bug 864033 is another JS top crash with the same regression range, though no test case.
It doesn't crash since 23.0a1/20130423.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.