799118 - crash in js::ObjectImpl::readBarrier (PGO related)

Status: NEW

Description

[Alice0775 White]

This bug was filed from the Socorro interface and is 
report bp-b1a481c2-7764-46c7-8f39-0e7bf2121008 .
============================================================= 

I noticed when I test Bug 791233.

Reproducible: I can not.

Steps to Reproduce:
1. Open https://docs.google.com/document/d/1p7sd8R0EeN4vkoN54tK9wh-YyDUsZQlzTqFct01PM9I/edit?pli=1
2. Select a line "【テキスト中に現れる記号について】"
3. Change Font size to 24

7. Click undo icon
8. Change Font size to 24

9. Repeat Step7-8 several time(4-5)

Actual Results:  
  Browser crashes

Comment 1

[Scoobidiver (away)]

It spiked from 19.0a1/20121010. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=aa5e3b445810&tochange=ec10630b1a54

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3AObjectImpl%3A%3AreadBarrier%28js%3A%3AObjectImpl*%29

Comment 2

[Scoobidiver (away)]

It's #2 top crasher in today's build.

Comment 3

[David Mandelin [:dmandelin]]

The stacks are showing this as an NPE on obj->compartment() in readBarrier. But they look kind of bogus: they are showing being called via a call to hasType() in TypeMonitorResult, and I don't see the path from there to readBarrier.

Comment 4

[Andrew McCreight [:mccr8]]

Could be some kind of IonMonkey-ish memory corruption. I've seen stacks like that before from that.  Bug 798624 in that range is JS and string-related...

Comment 5

[Alex Keybl [:akeybl]]

This continues to be a top 4 crasher, and we appear to have reproducible steps in comment 0. Is anything else needed to make this actionable?

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I don't think comment 0 reproduces. It says "Reproducible: I can not".

Comment 7

[Tyler Downer [:Tyler]]

I ran into this today, bp-3c3f158c-350c-4f39-aaee-5399b2121019. It's reproducible on our SUMO site admin side (ping me privately for Reproducible details).

Comment 8

[Andrew McCreight [:mccr8]]

I don't know if this helps, but these crashes are all null-derefs, on this line:
  JSCompartment *comp = obj->compartment();

Comment 9

[Scoobidiver (away)]

There's only one crash in 19.0a1/20121024 while there were 71 ones in the previous build.

Alice, is it still reproducible for you?

Comment 10

[Alice0775 White]

(In reply to Scoobidiver from comment #9)
> There's only one crash in 19.0a1/20121024 while there were 71 ones in the
> previous build.
> 
> Alice, is it still reproducible for you?

Reproducible: I can not.

Comment 11

[Alex Keybl [:akeybl]]

(In reply to Bill McCloskey (:billm) from comment #6)
> I don't think comment 0 reproduces. It says "Reproducible: I can not".

Was confused by "Steps to Reproduce", and missed that line. Thanks.

Comment 12

[Scoobidiver (away)]

It stopped in builds from October 24th and 25th but it's back to its previous volume in the build from October 26th. It might be related to PGO.

Comment 13

[Scoobidiver (away)]

It stopped in 19.0a1/20121027.

Comment 14

[Naveed Ihsanullah [:naveed]]

The possible stack corruption (see between ObjectImpl-inl.h:382  and js/src/jsinfer.cpp:5377) as well as the PGO fix in the regression range (http://hg.mozilla.org/mozilla-central/rev/5cca0408a73f) makes me believe this is also a PGO issue. Since it is not reproducible there isn't much more we can do at the moment.

Comment 15

[Scoobidiver (away)]

It appeared again in 19.0a1/20121102.

Comment 16

[Scoobidiver (away)]

It has spiked since 20.0a1/20121203 along with bug 790473.

Comment 17

[Tyler Downer [:Tyler]]

For what it's worth, I tried again today and can't reproduce in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130313 Firefox/22.0

Comment 18

[Stebs]

Reproducible steps:
1. set javascript.options.experimental_asmjs to false 
2. Go to http://kripken.github.com/misc-js-benchmarks/banana/benchmark.html
3. Run the Benchmark (either GO! and Goheadless! crashes)

no crash when setting javascript.options.experimental_asmjs to true (default for Nightly and Aurora)

bp-f8f6d5cd-ec19-48f7-ae04-cb2d92130322
bp-be6df390-0d0c-490c-bf4e-a5a882130322
bp-ce594afa-d4bf-4cfb-840d-29e5c2130322

Comment 19

[Scoobidiver (away)]

I can reproduce the crash with the STR in comment 18.

Comment 20

[Andrew McCreight [:mccr8]]

Please file a new bug, that seems like a new issue unrelated to PGO.  It is presumably a regression from the OdinMonkey landing.

Comment 21

[Alice0775 White]

under condition of javascript.options.experimental_asmjs to false: 

Crash(Regular nightly m-c build, ie. PGO build): 
bp-1d0ee220-8cc9-48e6-aae0-c34e22130322
http://hg.mozilla.org/mozilla-central/rev/0e9badd3cf39
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130322 Firefox/22.0 ID:20130322031028

Not Crash(tinderbox hourly m-c build, ie. not PGO):
http://hg.mozilla.org/mozilla-central/rev/0e9badd3cf39
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130321 Firefox/22.0 ID:20130321134616

So, the crashes is definitely related to PGO.

Comment 22

[Robert Kaiser]

(In reply to Andrew McCreight [:mccr8] from comment #20)
> Please file a new bug, that seems like a new issue unrelated to PGO.  It is
> presumably a regression from the OdinMonkey landing.

Note that the STR say that this crash happens when OdinMonkey is turned *off* and doesn't crash when it's actually active.