864125 - crash in js::ion::DoTypeMonitorFallback

Status: RESOLVED DUPLICATE of bug 860145

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It started spiking in 23.0a1/20130420 and is #2-3 top crasher in this build. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=64d6d002e888&tochange=dd03d42b01b1

Signature 	js::types::TypeSet::hasType(js::types::Type) More Reports Search
UUID	3b843948-045e-4225-8b20-e2ee32130420
Date Processed	2013-04-20 22:45:46
Uptime	2526
Install Age	3.8 hours since version was first installed.
Install Time	2013-04-20 18:55:37
Product	Firefox
Version	23.0a1
Build ID	20130420040201
Release Channel	nightly-ux
OS	Windows NT
OS Version	6.2.9200
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0xe
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0398, AdapterSubsysID: 00000000, AdapterDriverVersion: 7.15.11.7948
D2D? D2D- D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ 
Processor Notes 	sp-processor01.phx1.mozilla.com_9550:2012; non-integer value of "SecondsSinceLastCrash"; exploitability tool failed: 127
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x0398
Total Virtual Memory	4294836224
Available Virtual Memory	3503640576
System Memory Use Percentage	49
Available Page File	4469010432
Available Physical Memory	1633992704

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::types::TypeSet::hasType 	js/src/jsinferinlines.h:1394
1 	mozjs.dll 	js::types::TypeScript::SetArgument 	js/src/jsinferinlines.h:1111
2 	mozjs.dll 	js::ion::DoTypeMonitorFallback 	js/src/ion/BaselineIC.cpp:1158
3 		@0x2c808a51 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeSet%3A%3AhasType%28js%3A%3Atypes%3A%3AType%29
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AGetValueType%28JSContext*%2C+JS%3A%3AValue+const%26%29
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3AICTypeMonitor_Fallback%3A%3AaddMonitorStubForValue%28JSContext*%2C+JS%3A%3AHandle%3CJSScript*%3E%2C+JS%3A%3AHandle%3CJS%3A%3AValue%3E%29
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ADoTypeMonitorFallback

Comment 1

[Nicolas B. Pierron [:nbp]]

This bug is likely a duplicate of Bug 864033, and thus likely caused by either bug 860145 or bug 861841.

Comment 2

[Scoobidiver (away)]

Probably also a duplicate of bug 864037 because http://qt-project.org/downloads reproduce it: bp-a13edd6f-4f8d-45f8-9e75-86d4a2130422.

Comment 3

[Alex Keybl [:akeybl]]

Naveed - looks like a recent regression on m-c. Can we get an assignee? Thanks!

Comment 4

[Georg Fritzsche [:gfritzsche]]

This is one of the stack contents i am seeing for a reproducible crash:
bp-0c84328f-d802-49ee-9a24-7605e2130422
bp-ecd7cfdc-cc27-4535-b14e-f8f7e2130422

The stacks are incomplete, so this is quite possibly the same crash.

Reliable repro (for me at least):
1. irccloud.com, open channel with a few days of backlog
2. scroll up, causing it to fetch more history
3. scroll back in history for a few days
4. ... after some time... crash.

Comment 6

[Andrew McCreight [:mccr8]]

bug 864495 has another example page that causes this crash, on windows.  it can also cause the compartment checker to fail sometimes.

Comment 8

[Daniel Veditz [:dveditz]]

Over in bug 864543 Tanner Filip reports being able to reliably reproduce this with the following STR:

1. http://backpack.tf/id/76561198025325750
2. "Sort by position" -> Any other option in that dropdown

This did not reproduce in safe-mode so one (or more) of these 19 add-ons is contributing to the necessary conditions.
https://crash-stats.mozilla.com/report/index/e2106f74-869a-412c-b456-2d68c2130422#extensions

Comment 9

[Gian-Carlo Pascutto [:gcp]]

Opening this link is an instant crash for me: 
http://www.keye.pl/games/product/id/7804/EVE-Online-Prepaid-30-Dni

Comment 10

[Nicolas B. Pierron [:nbp]]

I cannot reproduce a crash with any of the website reported here.  This might be related to the fact that the following crashes are no longer reproducing, at least based on crash-stat:

(In reply to Scoobidiver from comment #0)
> https://crash-stats.mozilla.com/report/
> list?signature=js%3A%3Atypes%3A%3AGetValueType%28JSContext*%2C+JS%3A%3AValue+
> const%26%29
> https://crash-stats.mozilla.com/report/
> list?signature=js%3A%3Aion%3A%3AICTypeMonitor_Fallback%3A%3AaddMonitorStubFor
> Value%28JSContext*%2C+JS%3A%3AHandle%3CJSScript*%3E%2C+JS%3A%3AHandle%3CJS%3A
> %3AValue%3E%29
> https://crash-stats.mozilla.com/report/
> list?signature=js%3A%3Aion%3A%3ADoTypeMonitorFallback

As this bug is the host of multiple *unrelated* crash-stat signature, I'll consider it to be related to the most important crashes which where present a few days ago, even if the title of the bug relate to the lowest crash rate.

As the most common source of crashes are no longer reproducing I will mark this Bug as a duplicate of the fix (which is the bug itself, as it got backout and re-landed with a fix).  

Please open a new bug for the remaining crashes, with the correct priorities.

> https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeSet%3A%3AhasType%28js%3A%3Atypes%3A%3AType%29

Note: Please, stop using one bug for unrelated signatures.  I would prefer one bug per crash signature as opposed to one bug for a collection of them, especially when the stack are so different.  A bug can be marked as a duplicate of another, but we cannot extract a bug easily from another.  Which means that the problem I identified in comment 1 is now fixed.

Note: If you want to know if I can handle a bug, use need-info, thanks.

Comment 11

[Scoobidiver (away)]

(In reply to Nicolas B. Pierron [:nbp] from comment #10)
> > https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeSet%3A%3AhasType%28js%3A%3Atypes%3A%3AType%29
Is bp-29bf9904-ec69-437d-9b11-fcb9e2130425 not related to these crashes?

> Note: Please, stop using one bug for unrelated signatures.  I would prefer
> one bug per crash signature as opposed to one bug for a collection of them,
> especially when the stack are so different. 
Except the first frames, stack traces were the same for every signatures of this bug. If some crash signatures have various stack traces, they are connected to different bugs depending on them.

Comment 12

[Nicolas B. Pierron [:nbp]]

tl;dr: Crash-stat bugs are used to change the priority of fuzz-bugs, because the probability that a fuzz-bug highlight the issue seen in a crash-stat is higher than the ratio of time needed to fix a fuzz-bug vs. a crash-stat bug.

(In reply to Scoobidiver from comment #11)
> (In reply to Nicolas B. Pierron [:nbp] from comment #10)
> > > https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeSet%3A%3AhasType%28js%3A%3Atypes%3A%3AType%29
> Is bp-29bf9904-ec69-437d-9b11-fcb9e2130425 not related to these crashes?

Based on the graph related to this signature, it seems like we got a bug which suddenly spiked with the apparition of the other issue (now fixed), and base on the time-frame for which this bug got opened. I assume this bug is related to the spike, and not the background bug from which this signature is coming from.

> > Note: Please, stop using one bug for unrelated signatures.  I would prefer
> > one bug per crash signature as opposed to one bug for a collection of them,
> > especially when the stack are so different. 
> Except the first frames, stack traces were the same for every signatures of
> this bug. If some crash signatures have various stack traces, they are
> connected to different bugs depending on them.

My point is, most of the time, crash-stat bugs are fuzzy[1].  We have no clear view of what should be fixed.  **We don't have time to address all bugs.**  Addressing a fuzzy bugs takes way more time than one with a reproducible test case and a regression range.  And one with a test case is likely to address crash-stat bugs.

This is for this exact reason that we are trying to work on fuzz bugs which are similar to what is reported in crash-stats, when such bug is opened.  As this bugs highlight, some work has been done to address the issue, as the spike disappeared.  The work has been done in fuzz-bugs and not on this one.  The reason is that fuzz-bugs are strict working/non-working state, with a clear way to reproduce them.

[1] crash-stat JS issues, have stack traces which are ~3 frames deeps.  We can hardly take any action without more context.  Every-time I am looking at crash-stat bugs, I have to look at the general address which is either read / write and guess if this correspond to any offset in one of the manipulated structures.  That way I can guess which member contains a bad/corrupted value.  Then the lack of context and reproducible test case takes over and we are just unable to take any action on these bugs.

Comment 13

[Robert Kaiser]

(In reply to Nicolas B. Pierron [:nbp] from comment #12)
> As
> this bugs highlight, some work has been done to address the issue, as the
> spike disappeared.  The work has been done in fuzz-bugs and not on this one.
> The reason is that fuzz-bugs are strict working/non-working state, with a
> clear way to reproduce them.

No. The worst offender that caused crashes was just backed out *because of crash-stats and developers seeing the crashes*, not because of fuzzing. I agree with I good part of the rest you are seeing, but in this case, work was not done in fuzz bugs.

Comment 14

[Nicolas B. Pierron [:nbp]]

(In reply to Robert Kaiser (:[e-mail]) from comment #13)
> (In reply to Nicolas B. Pierron [:nbp] from comment #12)
> > As
> > this bugs highlight, some work has been done to address the issue, as the
> > spike disappeared.  The work has been done in fuzz-bugs and not on this one.
> > The reason is that fuzz-bugs are strict working/non-working state, with a
> > clear way to reproduce them.
> 
> No. The worst offender that caused crashes was just backed out *because of
> crash-stats and developers seeing the crashes*, […]

It has been backout on the 22, and re-landed on the 24.
The spikes for which this bug was made for did not reappear on the 24 or after.

> […] , not because of fuzzing. […] but in this case, work was not done in fuzz bugs.

As far as I can tell Bug 864002 is a fuzz bug, and it has been landed on the 24 also.
I did not investigated to know if the issue was fix by the re-landing of Bug 860145 or by the landing of Bug 864002.  If you have time and fell like this is absolutely necessary to know which one is shipping the fix, fell free to dig in.