This bug was filed from the Socorro interface and is report bp-7993051a-66c0-4fe0-a2e5-f9c742131023. =============================================================

1. https://admin.ecommerce.aruba.it/epages/15047.sf/it_IT/?ObjectPath=/Shops/15047&ViewAction=ViewRegistration on Windows. 2. Crash bp-cdbc74c4-6c25-422d-ad03-15d7f2131110 0 @0x1d0315a7 1 mozjs.dll js::CloneFunctionObject(JSContext *,JS::Handle<JSFunction *>,JS::Handle<JSObject *>,js::gc::AllocKind,js::NewObjectKind) js/src/jsfun.cpp 2 mozjs.dll js::jit::Compile js/src/jit/Ion.cpp 3 mozjs.dll DefinePropertyById js/src/jsapi.cpp 4 xul.dll nsRuleNode::ComputeTextData(void *,nsRuleData const *,nsStyleContext *,nsRuleNode *,nsRuleNode::RuleDetail,bool) layout/style/nsRuleNode.cpp 5 xul.dll nsINode::GetNodeName(mozilla::dom::DOMString &) obj-firefox/dist/include/nsINode.h Debug builds give on Windows for Nightly and Aurora: Crash reason: EXCEPTION_ACCESS_VIOLATION_READ Crash address: 0x5 Thread 0 (crashed) 0 0xca62cf eip = 0x00ca62cf esp = 0x00294f84 ebp = 0xffffff87 ebx = 0xffffff87 esi = 0x652c5188 edi = 0x0ae18980 eax = 0x00000001 ecx = 0xffffff87 edx = 0x093f4eb0 efl = 0x00010246 Found by: given as instruction pointer in context 1 mozjs.dll!js::gc::BarrieredCell<js::Shape>::shadowZoneFromAnyThread() [Barrier.h : 157 + 0xd] eip = 0x64a6d5b5 esp = 0x00294f9c ebp = 0xffffff87 Found by: stack scanning Found regression between 20131001030204-20131001030204 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6b92cb377496&tochange=6b92cb377496 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-01-03-02-04-mozilla-central/firefox-27.0a1.en-US.win32.zip http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-01-03-02-04-mozilla-central/firefox-27.0a1.en-US.win32.installer.exe Note this is the same regression range as Bug 936953

Kevin why is this a tracking nomination? Bug 936953 with the same regression window is not tracking, these reports a from a month ago, and there's no indication this is a topcrash - can you explain your thinking here?

This is the top crash for 27 beta 1, might be related to or fixed by bug 944094 as this stack is what he gets from crash stats.

The report in comment 1 has exactly the same symptoms (pointer value 0x5, just before three cmp's in JIT code) that I saw in bug 943366, which was fixed on December 20. I'm not sure whether that will actually fix the Android crash. They may be two separate root causes getting mixed into the same bucket. The stacks look incomplete enough that it wouldn't surprise me.

Setting a needinfo on myself to check the next beta which has the fix for bug 943366.

I tested the crash from 944094 with 27 beta 4 and current nightly. I am still able to reproduce. We should work with the assumption that this is not fixed. It will be Thursday before we get data.

Given comment #6, NI Kannan to see if he has any idea's here to help with Fx27 to avoid shipping with this top-crasher. We only have a handful of beta's left and urgent investigation here will be really helpful. Thanks !

This is still the top crasher and now may be resolved by 957475.

(In reply to Kevin Brosnan [:kbrosnan] from comment #8) > This is still the top crasher and now may be resolved by 957475. NI on :kbrosnan to confirm this is fixed. I am not seeing any crashes on 27.0b6(http://bit.ly/1eU0w8t), cross-check would be helpful. Thanks !

This is still crashing. Looks slightly lowered in volume.

NI on :nbp to help with urgent investigation here as the patch in 957475, does not seem to have resolve this :(

I was looking at the regression range of Bug 936953, within this range I do not see any patch which is likely to have caused this issue on both Window and Android.

1 mozjs.dll js::CloneFunctionObject(JSContext *,JS::Handle<JSFunction *>,JS::Handle<JSObject *>,js::gc::AllocKind,js::NewObjectKind) js/src/jsfun.cpp 2 mozjs.dll js::jit::Compile js/src/jit/Ion.cpp I tried to male sense of this stack or of the other one reported in crash reports where there is no stack under js::CloneFunctionObject, but I failed to have an interpretation of what might be wrong there. The only possible interpretation that I have of js::CloneFunctionObject ?? is: js::CloneFunctionObject js::CloneFunctionAtCallSite js::jit::InvokeFunction <ion> (emitCallInvokeFunction) AFAIK, The reasons for calling js::CloneFunctionObject, is when we are either cloning a self-hosted function or when TI prefer to clone the function based on the call-site such as we are collecting a type information which is related to the caller.

I am unable to reproduce this issue with neither the URL provided in comment 1, nor Bug 936953 comment 0.

(In reply to Nicolas B. Pierron [:nbp] from comment #14) > I am unable to reproduce this issue with neither the URL provided in comment > 1, nor Bug 936953 comment 0. I tried on the latest B2G running on Unagi. And on a Firefox for Android 29.0a1 (2014-01-03) on a Nexus 5. If this is only a JS engine issue, we should likely have the same issues on both B2G and Firefox for Android. Except for the GC settings both should behave identically (except if they have a different number of cores).

(In reply to Nicolas B. Pierron [:nbp] from comment #15) > (In reply to Nicolas B. Pierron [:nbp] from comment #14) > > I am unable to reproduce this issue with neither the URL provided in comment > > 1, nor Bug 936953 comment 0. > > I tried on the latest B2G running on Unagi. And on a Firefox for Android > 29.0a1 (2014-01-03) on a Nexus 5. :kbrosnan, were you able to repro this on nexus 5 per comment https://bugzilla.mozilla.org/show_bug.cgi?id=930735#c6 or can see if you are ? or is this device specific ? > > If this is only a JS engine issue, we should likely have the same issues on > both B2G and Firefox for Android. > Except for the GC settings both should behave identically (except if they > have a different number of cores).

I was before the fix for bug 957475. Current status is that I am checking the current urls for the post beta 6 crashes and seeing if any reproduce.

So the patch for bug 957475 did not make it into beta 8. So we spun our wheels here.

(In reply to Kevin Brosnan [:kbrosnan] from comment #18) > So the patch for bug 957475 did not make it into beta 8. So we spun our > wheels here. Umm, you mean it missed beta 6, I guess. It should have made it for beta 8.

The "Product" signature summary for https://crash-stats.mozilla.com/report/list?signature=js%3A%3ACloneFunctionObject%28JSContext*%2C+JS%3A%3AHandle%3CJSFunction*%3E%2C+JS%3A%3AHandle%3CJSObject*%3E%2C+js%3A%3Agc%3A%3AAllocKind%2C+js%3A%3ANewObjectKind%29 says this signature is gone from 27.0b8 for Android.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #20) > The "Product" signature summary for > https://crash-stats.mozilla.com/report/ > list?signature=js%3A%3ACloneFunctionObject%28JSContext*%2C+JS%3A%3AHandle%3CJ > SFunction*%3E%2C+JS%3A%3AHandle%3CJSObject*%3E%2C+js%3A%3Agc%3A%3AAllocKind%2 > C+js%3A%3ANewObjectKind%29 says this signature is gone from 27.0b8 for > Android. Marking it fixed then. Thanks. Patch in 957475 which went into beta 8 has helped here.

(In reply to bhavana bajaj [:bajaj] from comment #21) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #20) > Marking it fixed then. Thanks. Patch in 957475 which went into beta 8 has > helped here. Should we marked this bug as resolved?

The Android signature has been resolved. It still is a low volume crasher on Desktop from looking at the signature page. Likely best to happen in a new bug.