This bug was filed from the Socorro interface and is report bp-42f2a9a7-cf85-4cfa-8938-2711f2141126. ============================================================= No exact STR, just browsing and crash is random, sometimes when doing nothing with the browser, just idling with 12 tabs open. Only CNN.com and https://tbpl.mozilla.org/ have any active javascript. Tested in new profile, and with addons disabled, still will randomly crash. I will try running leaving CNN & TBPL closed for now and see if I still crash. This could well be a dupe of bug 1102457, but I tested that build/patch and I was still crashing with https://bugzilla.mozilla.org/show_bug.cgi?id=1103032 fixed. (I could not look at bug as I don't have 'security' rights.

I can reproduce it on a new profile by opening this pdf with built-in pdf.js: http://www.nagasaki-bus.co.jp/bus/pdf/bus_map.pdf Nightly crashes with e10s enabled or disabled. I'm using Nightly 2014-11-26 32bit build in Win8.1.

I can reproduce with the following pdf: http://gene.pku.edu.cn/media/publication/papers/Streets_COBT_review_2014.pdf

I get this crash only with e10s enabled, if I open www.golem.de and wait a few seconds. I also get it with disabled Flash Plugin. https://crash-stats.mozilla.com/report/index/627b14c9-dd5e-45ea-b832-cbc2f2141128

I had this crash without e10s, also browsing a pdf using pdf.js https://crash-stats.mozilla.com/report/index/ec4fec9b-1225-409f-8d1d-5da4a2141128

In addition to my comment above: opening this PDF file leads to a crash after a few seconds http://www.oresundstag.se/Global/Tidtabeller/2014/%C3%98,1%20Lund%20-%20Malm%C3%B6%20-%20CPH%20Airport%20-%20K%C3%B6penhamn_2013-12-15-2014-12-13.pdf

Opening PDF's seems to be a quick way to crash. I've been doing testing, and CNN main page open, will crash after an unknown period of time, it always crashes when I'm away, but some piece of javascript on the main page is likely triggering the crash. I'm fearing/wondering now that m-c to Aurora has occurred today that this crasher is going to affect a lot more folks.

This has become #1 crasher over-night.

STR on Comment#5 Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/2471a54e5a5a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141124071142 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/9188c8b7962b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141124071347 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2471a54e5a5a&tochange=9188c8b7962b Triggered by: 9188c8b7962b Nicolas B. Pierron — Bug 1093674 - IonMonkey: Add Sink for instruction which can be recovered on bailout. r=sunfish

This is bug 1106171. Nicolas, #1 crasher so maybe we should backout or disable if we can't fix this quickly.

Hit this one as well on https://www.drivy.com when clicking on a link after scrolling down a long list.

I believe I have found another site that incites an Aurora (both x32 and x64) crash: http://www.eur.army.mil/training/USAREURTrainingHolidaySchedule-FY2014.pdf

Hit this while trying to shop. Any update on reverting this?

And in case you'd like a non-pdf test-case, it's happening to me at <http://strilanc.com/quantum/2014/12/06/Perfect-Symmetry-Breaking-with-Quantum-Computers.html>; just mouse over the evolving gates and then away.

Just started to hit this crash as well two days ago, probably because I don't restart/update nightly every day. Is this what other people are seeing as well? http://i.imgur.com/vjVS2U7.png

This is 21% of all crashes on Nightly, three times the volume of the next most common crash.

(In reply to Jan de Mooij [:jandem] from comment #9) > This is bug 1106171. Nicolas, #1 crasher so maybe we should backout or > disable if we can't fix this quickly. Bug 1106171 did not fix this issue, crashes with this sig are still appearing. Yesterday: https://crash-stats.mozilla.com/report/index/e32ae794-a604-48f1-b740-c704c2141207 crashed while minimized and I was away from computer overnight. Same tab set as I reported above.

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #17) > (In reply to Jan de Mooij [:jandem] from comment #9) > > This is bug 1106171. Nicolas, #1 crasher so maybe we should backout or > > disable if we can't fix this quickly. > > Bug 1106171 did not fix this issue, crashes with this sig are still > appearing. The feature is now disabled (as part of Bug 1093674) until all reported issues are fixed. Apparently, many crashes had the same signature, which explain why Bug 1106171 did not fixed all the crashes but still fix the test case. Thank you all for reporting this issue, and sorry for the trouble.

It just happened to me on 9 Dec Aurora (36.0a2), with the same link I gave above--unless the fix you are talking about is on Nightly.... (In reply to Nicolas B. Pierron [:nbp] from comment #18) > > > The feature is now disabled (as part of Bug 1093674) until all reported > issues are fixed. Apparently, many crashes had the same signature, which > explain why Bug 1106171 did not fixed all the crashes but still fix the test > case. > > Thank you all for reporting this issue, and sorry for the trouble.

[Tracking Requested - why for this release]: This is the #1 top crash on Aurora 36 accounting for nearly 30% of all crashers on that train. I'm just trying to make sure this stays in our radar.

I'm curious why this is still the #1 crasher on Aurora 36. Is there anything we can do about it for Aurora? Since Jim won't be able to respond for a couple of weeks, I will ask Nicolas.

(In reply to juan becerra [:juanb] from comment #21) > I'm curious why this is still the #1 crasher on Aurora 36. Is there anything > we can do about it for Aurora? Since Jim won't be able to respond for a > couple of weeks, I will ask Nicolas. I have no idea, but crash-stat does not report any recent build ID as crashing at this address. The latest build ID are 20141209004001 on Aurora. https://crash-stats.mozilla.com/report/list?product=Firefox&range_unit=days&version=Firefox%3A36.0a2&signature=js%3A%3Ajit%3A%3ALiveRangeAllocator%3Cjs%3A%3Ajit%3A%3ALinearScanVirtualRegister%2C+int%3E%3A%3AbuildLivenessInfo%28%29&date=2014-12-15&range_value=28#tab-reports I guess this might be the time required for our Aurora users to update to a newer build, and which are still using old builds while the update is being downloaded?

Or they also just wait until it gets too slow, crashes or other reasons. Those are the reasons I restart my nightly, not because I want to update every day.

Seems to be fixed, not tracking