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 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
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?
tracking-firefox19: ? → +
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?
tracking-firefox19: + → ?
(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.
(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: ? → -
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: - → ?
It stopped in 19.0a1/20121027.
tracking-firefox19: ? → ---
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
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.
(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.
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.