Closed Bug 933734 Opened 6 years ago Closed 6 years ago

google drive crashes with 11/1 nightly js::ObjectImpl::nativeLookup js::jit::DoTypeMonitorFallback

Categories

(Core :: JavaScript Engine: JIT, defect, critical)

25 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox27 --- unaffected
firefox28 + verified

People

(Reporter: mcmanus, Assigned: bhackett)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Today's nightly (11/1) is crashtastic for me working with google drive documents on 32bit windows 7. The same nightly on 64 bit linux is fine.

It happens when I load a doc from a bookmark, or even when I get the drive index of my files.

Here are 2 crash reports

https://crash-stats.mozilla.com/report/index/34d7861f-6787-4188-80c3-101862131101
https://crash-stats.mozilla.com/report/index/994e13ce-649a-4a29-8e94-393772131101
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/753a91f79d6f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131031170043
Bad:
http://hg.mozilla.org/mozilla-central/rev/4813677c42bf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131031180143
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=753a91f79d6f&tochange=4813677c42bf


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9d0bf12c1d1d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131029145620
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/636620b3af0a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131029151120
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9d0bf12c1d1d&tochange=636620b3af0a
Regressed by:
636620b3af0a	Brian Hackett — Bug 930048 - Remove need to read objects directly when optimizing singleton accesses, r=jandem.
Blocks: 930048
Keywords: crash, regression
Severity: blocker → critical
Is this windows only or 32 bit only?
(In reply to Brian Hackett (:bhackett) from comment #2)
> Is this windows only or 32 bit only?

I just tried it with linux-32 and didn't have a crash - so that implies it is windows centric.
Does not crash on Linux-64bit
http://hg.mozilla.org/mozilla-central/rev/abe6790a5dd8
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131101030205

Crash on Win64 and Win32
http://hg.mozilla.org/mozilla-central/rev/abe6790a5dd8
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131101030205
http://hg.mozilla.org/mozilla-central/rev/abe6790a5dd8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131101030205
bhackett, can you take this bug?
Flags: needinfo?(bhackett1024)
Can confirm this on Windows 8.1 64-bit with both 32-bit and 64-bit Nightly, so it isn't centric to just Windows 7 either. If needed I could check with 32-bit Nightly on a Windows XP machine as well. Just recently I opened Google Drive and the page just kinda froze at "Loading..." (the little yellow info box on the top of the page), but a refresh caused the crash again; was probably just a fluke in that it didn't crash that one time or something.
Duplicate of this bug: 933890
Crash Signature: [@ js::ObjectImpl::nativeLookup(js::ExclusiveContext*, int) ]
bp-a14d6feb-12ec-4c38-961c-c080c2131101
Crash Signature: [@ js::ObjectImpl::nativeLookup(js::ExclusiveContext*, int) ] → [@ js::ObjectImpl::nativeLookup(js::ExclusiveContext*, int) ] [@ js::jit::DoTypeMonitorFallback ] [@ js::types::TypeScript::SetArgument(JSContext*, JSScript*, unsigned int, js::types::Type) ]
Attached patch patchSplinter Review
This fixes the crash for me.  I think that somewhere there is a global object with an undefined property but non-empty types for that property (which shouldn't be happening) and this is causing IonBuilder to emit writes which overwrite the payload but not the type tag.  While the underlying reason for this still needs to be found and fixed (and this patch eliminated) this should fix the crash.
Assignee: nobody → bhackett1024
Attachment #826152 - Flags: review?(jdemooij)
Flags: needinfo?(bhackett1024)
https://hg.mozilla.org/mozilla-central/rev/6fd8199adc93
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Attachment #826152 - Flags: review?(jdemooij) → review+
Can we get a follow-up bug for finding the underlying cause and a test for this crash?
Flags: in-testsuite?
This has caused a huge spike in crashes in Firefox 28.0a1, see bug 933776 comment 7 and onward.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> This has caused a huge spike in crashes in Firefox 28.0a1, see bug 933776
> comment 7 and onward.

FWIW, the signature here is also spiking:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3AObjectImpl%3A%3AnativeLookup%28js%3A%3AExclusiveContext%2A%2C%20int%29
Depends on: 935324
Patrick, is this reproducible for you anymore?
Flags: needinfo?(mcmanus)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #17)
> Patrick, is this reproducible for you anymore?

no
Flags: needinfo?(mcmanus)
Verified fixed based on comment 18. Thank you Patrick.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.