Closed Bug 799118 Opened 7 years ago Closed Last year

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

Categories

(Core :: JavaScript Engine, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: alice0775, Unassigned)

References

()

Details

(Keywords: crash, reproducible)

Crash Data

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
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...
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?
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();
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?
(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.
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.
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.
It stopped in 19.0a1/20121027.
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.
It appeared again in 19.0a1/20121102.
Summary: crash in js::ObjectImpl::readBarrier → crash in js::ObjectImpl::readBarrier (PGO related)
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
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
I can reproduce the crash with the STR in comment 18.
Please file a new bug, that seems like a new issue unrelated to PGO.  It is presumably a regression from the OdinMonkey landing.
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.
(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.
Keywords: regression
Version: 19 Branch → Trunk
Blocks: 889937
Assignee: general → nobody
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)] [@ js::ObjectImpl::readBarrier]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
Closing because no crash reported since 12 weeks.
You need to log in before you can comment on or make changes to this bug.