Closed Bug 1005646 Opened 6 years ago Closed 6 years ago

crash in js::jit::AssemblerX86Shared::jSrc(js::jit::AssemblerX86Shared::Condition, js::jit::Label*)


(Core :: JavaScript Engine: JIT, defect, critical)

Not set





(Reporter: ehoogeveen, Unassigned)




(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-d659a2ed-7179-4bb3-88fc-d1af12140504.

I get this crash consistently when going to any channel page on using today's Nightly. Other crash comments mention It happens using a fresh profile with all plugins disabled. Setting javascript.options.ion to false fixes the crash.

I narrowed the range down on inbound:

Last Good:
First Bad:
Regression Range:

bz, which of these do you think is responsible?
Flags: needinfo?(bzbarsky)
Duplicate of this bug: 1005665
I've confirmed locally that this crash happens after applying the patch from bug 1004198, so setting this as blocking that bug. I'm also adding the crash signature from duplicate bug 1005665.
Blocks: 1004198
Crash Signature: [@ js::jit::AssemblerX86Shared::jSrc(js::jit::AssemblerX86Shared::Condition, js::jit::Label*)] → [@ js::jit::AssemblerX86Shared::jSrc(js::jit::AssemblerX86Shared::Condition, js::jit::Label*)] [@ js::jit::AssemblerX86Shared::j(js::jit::AssemblerX86Shared::Condition, js::jit::Label*)] is another site that crashes constantly.
Pretty sure this is because an |OutOfLineTestObject| can be created and added (i.e. |addOutOfLineCode|) in |visitTestVAndBranch| without it being fully initialized by |testObjectEmulatesUndefinedKernel|, since bz's patch added some early return logic to |TestValueTruthyKernel| here:
I'd assume this is a duplicate of bug 1005590.

For what it's worth, the scenario of comment 5 can't happen with visitTestVAndBranch, but can happen with visitNotV (and sadly that wasn't caught by our test suite, unlike visitTestVAndBranch).
Depends on: 1005590
Flags: needinfo?(bzbarsky)
I've confirmed that the fix for bug 1005590 fixes this.
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1005590
I'm still getting this bug ( on upon sign-in (unfortunately, requires an account/CC# to reproduce).
Are you using a current tip inbound build?  I checked in the patch for bug 1005590 less than two hours ago.
05.05.14 Firefox 32.0a1 Crash Report [@ js::jit::AssemblerX86Shared::j(js::jit::AssemblerX86Shared::Condition, js::jit::Label*) ]
That build obviously can't have the patch, since its timestamped two hours before the patch was checked in.
Duplicate of this bug: 1006076
Duplicate of this bug: 1005794
Parent bug is protected, I'm still seeing this in today's Nightly.
Flags: needinfo?(bzbarsky)
Kyle, what's the build id of the build you're seeing this in?
Flags: needinfo?(bzbarsky)
Flags: needinfo?(kyle.leet)
And in particular, would that build be built from a revision that's a descendant of ?  I can check that given the hg changeset ID from about:buildconfig.
(In reply to Boris Zbarsky [:bz] from comment #15)
> And in particular, would that build be built from a revision that's a
> descendant of ?  I
> can check that given the hg changeset ID from about:buildconfig.
Flags: needinfo?(kyle.leet)
OK, that should have my patch for sure.  What site are you seeing the crash on?
In particular, I'm not seeing a crash on locally...
Flags: needinfo?(kyle.leet)
(In reply to Boris Zbarsky [:bz] from comment #18)
> OK, that should have my patch for sure.  What site are you seeing the crash
> on?
No reliable case. The crash happened when I changed tabs; though.

Other crashes*%29#tab-comments

Seem to suggest Twitch, presumably that's what your cset fixed? People on the same build as me , Can we reopen this bug, or make the parent not protected?
Flags: needinfo?(bzbarsky)
I asked whether we can open up bug 1005590.

That said, I just looked again and the crash report linked in comment 16 is from a build with timestamp 20140505030202, which is before the fix for bug 1005590 was checked in, and not matching the revision id in comment 17.

Looking at the other crashes with this signature and sorting by build timestamp, all of them are with 20140505030202 or earlier.
Flags: needinfo?(bzbarsky)
Checked with NTT and indeed I'm no longer on 20140505030202, presumably the update was silent after I crashed? Anyways, yeah, this is all old; sorry.

Any idea how I can check my version string without installing Nightly Tester Tools? It doesn't appear that it's printed on any about: pages.
Flags: needinfo?(kyle.leet)
The Firefox about dialog shows things like "32.0a1 (2014-05-03)".

But usually just the changeset id is the most useful thing...
FWIW, you can find the build ID by going to about:healthreport and looking at the raw data, it's in the first section of that raw data and called appBuildID.
You need to log in before you can comment on or make changes to this bug.