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

NEW
Unassigned

Status

()

--
critical
6 years ago
3 years ago

People

(Reporter: alice0775, Unassigned)

Tracking

({crash, reproducible})

Trunk
x86
Windows 7
crash, reproducible
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

(Reporter)

Description

6 years ago
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

6 years ago
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
tracking-firefox19: --- → ?
Keywords: regression, topcrash
Version: 18 Branch → 19 Branch

Comment 2

6 years ago
It's #2 top crasher in today's build.
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.
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

6 years ago
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?
tracking-firefox19: ? → +
Keywords: reproducible
I don't think comment 0 reproduces. It says "Reproducible: I can not".
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).
I don't know if this helps, but these crashes are all null-derefs, on this line:
  JSCompartment *comp = obj->compartment();

Comment 9

6 years ago
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?
tracking-firefox19: + → ?
Keywords: topcrash
(Reporter)

Comment 10

6 years ago
(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.

Updated

6 years ago
Keywords: reproducible
(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.
tracking-firefox19: ? → -

Comment 12

6 years ago
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.
tracking-firefox19: - → ?
Keywords: topcrash

Comment 13

6 years ago
It stopped in 19.0a1/20121027.
tracking-firefox19: ? → ---
Keywords: topcrash
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

6 years ago
It appeared again in 19.0a1/20121102.
Summary: crash in js::ObjectImpl::readBarrier → crash in js::ObjectImpl::readBarrier (PGO related)

Comment 16

6 years ago
It has spiked since 20.0a1/20121203 along with bug 790473.
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

6 years ago
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

6 years ago
I can reproduce the crash with the STR in comment 18.
Keywords: reproducible
Please file a new bug, that seems like a new issue unrelated to PGO.  It is presumably a regression from the OdinMonkey landing.
(Reporter)

Comment 21

6 years ago
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

6 years ago
(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.

Updated

6 years ago
Keywords: regression
Version: 19 Branch → Trunk
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Updated

3 years ago
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)] [@ js::ObjectImpl::readBarrier]
You need to log in before you can comment on or make changes to this bug.