Closed
Bug 799118
Opened 9 years ago
Closed 3 years ago
crash in js::ObjectImpl::readBarrier (PGO related)
Categories
(Core :: JavaScript Engine, defect)
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
Comment 1•9 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
Comment 2•9 years ago
|
||
It's #2 top crasher in today's build.
Comment 3•9 years ago
|
||
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•9 years ago
|
||
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•9 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?
Keywords: reproducible
I don't think comment 0 reproduces. It says "Reproducible: I can not".
Comment 7•9 years ago
|
||
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•9 years ago
|
||
I don't know if this helps, but these crashes are all null-derefs, on this line: JSCompartment *comp = obj->compartment();
Comment 9•9 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?
Keywords: topcrash
![]() |
Reporter | |
Comment 10•9 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•9 years ago
|
Keywords: reproducible
Comment 11•9 years ago
|
||
(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•9 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.
Keywords: topcrash
Comment 13•9 years ago
|
||
It stopped in 19.0a1/20121027.
tracking-firefox19:
? → ---
Keywords: topcrash
Comment 14•9 years ago
|
||
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•9 years ago
|
||
It appeared again in 19.0a1/20121102.
Summary: crash in js::ObjectImpl::readBarrier → crash in js::ObjectImpl::readBarrier (PGO related)
Comment 16•8 years ago
|
||
It has spiked since 20.0a1/20121203 along with bug 790473.
Comment 17•8 years ago
|
||
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•8 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•8 years ago
|
||
I can reproduce the crash with the STR in comment 18.
Keywords: reproducible
Comment 20•8 years ago
|
||
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•8 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•8 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•8 years ago
|
Keywords: regression
Version: 19 Branch → Trunk
Assignee | ||
Updated•7 years ago
|
Assignee: general → nobody
Updated•6 years ago
|
Crash Signature: [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)] → [@ js::ObjectImpl::readBarrier(js::ObjectImpl*)]
[@ js::ObjectImpl::readBarrier]
Comment 23•3 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Comment 24•3 years ago
|
||
Closing because no crash reported since 12 weeks.
You need to log in
before you can comment on or make changes to this bug.
Description
•