Closed Bug 869027 Opened 12 years ago Closed 12 years ago

crash in JS_HasPropertyById

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
23 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla24
Tracking Flags:
Tracking Status
firefox22 --- unaffected
firefox23 - affected
firefox24 --- affected

People

(Reporter: bws42, Assigned: khuey)

References

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is report bp-487ccfbc-2225-4e0e-a8c0-120b42130506 . ============================================================= I was trying to create a new Google Word Doc. I typed a few letters, noticed they weren't showing up then clicked on the document a few times and it broke :) I'd forgotten that editing google docs was currently broken, but I don't recall that bug mentioning crashes.
Assignee: nobody → general
Component: Editor → JavaScript Engine
There are other related signatures. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e47b184aba&tochange=b109e2dbf03b The stack trace looks like: Frame Module Signature Source 0 libxul.so JS_HasPropertyById js/src/vm/Shape.h:334 1 libxul.so xpc::WrapperFactory::WrapForSameCompartment js/xpconnect/wrappers/WrapperFactory.cpp:513 2 libxul.so JSCompartment::wrap js/src/jscompartment.cpp:171 3 libxul.so mozilla::dom::HTMLDocumentBinding::DOMProxyHandler::get obj-firefox/dom/bindings/HTMLDocumentBinding.cpp:2134 4 libxul.so js::Proxy::get js/src/jsproxy.cpp:2473 5 libxul.so proxy_GetGeneric js/src/jsproxy.cpp:2811 6 libxul.so js::DirectProxyHandler::get js/src/jsobjinlines.h:161 7 libxul.so js::CrossCompartmentWrapper::get js/src/jswrapper.cpp:310 8 libxul.so js::types::Type::objectKey const js/src/jsinferinlines.h:1357 9 libxul.so js::Proxy::get js/src/jsproxy.cpp:2473 10 libxul.so proxy_GetGeneric js/src/jsproxy.cpp:2811 11 libxul.so js::Interpret js/src/jsobjinlines.h:161 12 libxul.so js::Interpret js/src/jsinterp.cpp:1471 13 libxul.so js::BaseShape::getUnowned js/src/jsapi.h:600 14 firefox calloc memory/mozjemalloc/jemalloc.c:4178 15 libxul.so JSObject::growSlots obj-firefox/dist/include/js/Utility.h:151 16 libxul.so js::ObjectImpl::initializeSlotRange js/src/vm/ObjectImpl-inl.h:215 17 libxul.so JSObject::updateSlotsForSpan js/src/jsobj.cpp:2364 18 libxul.so JSFunction::initBoundFunction js/src/jsfun.cpp:1056 19 libxul.so js::NewFunction js/src/jsobjinlines.h:1616 20 libxul.so js_fun_bind js/src/jsfun.cpp:1236 21 libxul.so fun_bind js/src/jsfun.cpp:1203 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3ACompartmentChecker%3A%3Afail%28JSCompartment*%2C+JSCompartment*%29 https://crash-stats.mozilla.com/report/list?signature=js%3A%3AassertSameCompartment%3CJS%3A%3AHandle%3CJSObject*%3E%2C+JS%3A%3AHandle%3C__int64%3E+%3E%28JSContext*%2C+JS%3A%3AHandle%3CJSObject*%3E+const%26%2C+JS%3A%3AHandle%3C__int64%3E+const%26%29 https://crash-stats.mozilla.com/report/list?signature=JS_HasPropertyById%28JSContext*%2C+JSObject*%2C+int%2C+int*%29 https://crash-stats.mozilla.com/report/list?signature=JS_HasPropertyById%28JSContext*%2C+JSObject*%2C+long%2C+int*%29
Blocks: compartment-mismatch
Crash Signature: [@ JS_HasPropertyById(JSContext*, JSObject*, long, int*)] → [@ JS_HasPropertyById(JSContext*, JSObject*, long, int*)] [@ JS_HasPropertyById(JSContext*, JSObject*, int, int*) ] [@ js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<__int64> >(JSContext*, JS::Handle<JSObject*> const&, JS::Handle<__int64> c…
status-firefox22: --- → unaffected
status-firefox23: --- → affected
Keywords: regression
OS: Linux → All
Version: Trunk → 23 Branch
The dozen or so signatures for js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<__int64> >(JSContext*, JS::Handle<JSObject*> const&, JS::Handle<__int64> const&) all have a mozilla::dom::HTMLDocumentBinding::DOMProxyHandler method (mostly get, but I saw another one at least once) in the stack near the top, and the DOM bindings for document landing is in the range, so it seems related. The stacks for JS_HasPropertyById(JSContext*, JSObject*, long, int*) are similar, and they also all involve xpc::WrapperFactory::WrapForSameCompartment. For a random sampling of the stacks involving js::CompartmentChecker::fail(JSCompartment*, JSCompartment*), the newer ones mostly involved the same HTMLDocumentBinding stuff, while the older stacks were the standard soup of various problems we see. In particular, there's one comment that involves a long list of steps in the developer console, but that's bug 867771 and does not involve HTMLDocument. The stacks for a random sampling of JS_HasPropertyById(JSContext*, JSObject*, int, int*) mostly did not involve document, but they did often involve some bindings stuff, like for MutationObserver.
Blocks: 855971
Seems pretty likely...
Alright, let me know if you need anything from me, I can't see that issue.
Crash Signature: , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] → , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] [@ SearchTable ] [@ nsIFrame::Preserves3D() ]
Oops! I added some signatures belonging to bug 869158.
Crash Signature: , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] [@ SearchTable ] [@ nsIFrame::Preserves3D() ] → , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)]
There are about 500 crashes per build.
Severity: critical → blocker
tracking-firefox23: --- → ?
Keywords: topcrash
(In reply to Scoobidiver from comment #8) > There are about 500 crashes per build. And as said before, this is probably a dupe of bug 869038, which has a fix in inbound at this time.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > which has a fix in inbound at this time. Thanks for info!
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > this is probably a dupe of bug 869038 It doesn't seem so as there are still crashes in 23.0a1/20130509.
(In reply to Scoobidiver from comment #11) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > > this is probably a dupe of bug 869038 > It doesn't seem so as there are still crashes in 23.0a1/20130509. Hmm, that patch landed on m-c yesterday so 0509 should have the fix.
Nevertheless, the volume is lower than before the fix of bug 869038.
Severity: blocker → critical
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > (In reply to Scoobidiver from comment #8) > > There are about 500 crashes per build. > > And as said before, this is probably a dupe of bug 869038, which has a fix > in inbound at this time. I don't believe so, I'm still getting these crashes every time I restart my browser. https://crash-stats.mozilla.com/report/index/bp-6c933765-cffa-4789-b471-e95952130509 https://crash-stats.mozilla.com/report/index/bp-d4bbd1d5-8526-40c1-939c-3258a2130510 https://crash-stats.mozilla.com/report/index/bp-1338300f-cb15-43d1-a7cb-5c3302130510
Yes, we'll need the JS team to look into this one.
Flags: needinfo?(nihsanullah)
Weird, there's a CCW on the stack, so we should have entered the right compartment there.
(In reply to comment #16) > Weird, there's a CCW on the stack, so we should have entered the right > compartment there. Is there anything that I can do to help debug this? I can reproduce this quite reliably, it just happens after a long session. I'd even be willing to run a debug build for a while if you tell me what kinds of stuff you'd be interested to see to help debug this.
> Dupe of bug 869038? Fixing that didn't make this crash signature go away, but it did allow the fuzzer to uncover bug 871849. Is fixing that likely to help?
Depends on: 869038, 871849
Given the regression range and the call stacks, this seems like a DOM bug. (In reply to Jesse Ruderman from comment #18) > > Dupe of bug 869038? > > Fixing that didn't make this crash signature go away, but it did allow the > fuzzer to uncover bug 871849. Is fixing that likely to help? I'm not able to access this bug. Is it protected in some special way?
(In reply to Peter Van der Beken [:peterv] from comment #16) > Weird, there's a CCW on the stack, so we should have entered the right > compartment there. Even though the compartment checking assertion fires, this might not be a compartment bug. It might just be that we have a bad pointer and the compartment checker happens to fire on it. That would explain why we sometimes fail the compartment check and sometimes fail elsewhere. All the crash addresses in the JS_HasPropertyById crash look like 0xdadadada, which means that the object we're accessing has been swept by the GC. Maybe we're not tracing something that we should be tracing.
Peter, you were saying something about issues with HTMLDocument expando tracing?
Flags: needinfo?(peterv)
Depends on: 871294
(In reply to Bill McCloskey (:billm) from comment #20) > Even though the compartment checking assertion fires, this might not be a > compartment bug. Yeah, it's not. (In reply to Boris Zbarsky (:bz) from comment #21) > Peter, you were saying something about issues with HTMLDocument expando > tracing? I'm working on that in bug 871849 which has a testcase.
Flags: needinfo?(peterv)
I guess we'll blame this on DOM for now.
Assignee: general → nobody
Component: JavaScript Engine → DOM
Flags: needinfo?(nihsanullah)
Don't know if this adds something for you, but everytime I crashed with this signature (2 or 3 times) I was logging off from Gmail.
js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) signature shows a high URL correlation to GMail and Google+ URLs. Some other URLs for the various signatures: js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<__int64> >(JSContext*, JS::Handle<JSObject*> const&, JS::Handle<__int64> const&) 5 about:blank 2 about:addons 1 http://www.gamestorrents.com/eng/juegos-pc-bittorrent.html 1 http://motherless.com/GI9C35C5B# 1 http://de.minecraftwiki.net/wiki/Trichter 1 https://www.google.com/search?q=R%E3%80%80%E6%96%87%E5%AD%97%E5%88%97%E3%80%80%E 1 http://www.aol.com/ 1 https://www.hsbc.co.uk/htse-ukpib-themeskins-servlet/screens/html/SessionWarning 1 https://groups.google.com/forum/?fromgroups#!newtopic/tekmil_hq_ipc 1 http://m2mbc.com/mail.php?mode=view_message 1 http://speed.cd/login.php 1 http://www.sk.rs/forum/showthread.php?p=1740525#post1740525 1 http://google.de/ 1 http://www.yellowbullet.com/forum/forumdisplay.php?f=119 1 chrome://lastpass/content/home2.xul 1 http://www.nhattao.com/forums/dien-thoai.144/page-5 1 https://www.paypal.com/ 1 http://fanda.nova.cz/clanek/fotky/raylene-2.html?image=1500009&psection_id=63120 1 https://www.facebook.com/ JS_HasPropertyById(JSContext*, JSObject*, long, int*) 4 https://www.facebook.com/ 2 about:plugins 1 https://www.facebook.com/groups/233890853370478/ 1 http://walmartlabs.blogspot.com/2013_05_01_archive.html 1 about:privatebrowsing 1 https://bitbucket.org/digintent/ppmd-app/ 1 http://www.google.com.br/ 1 https://docs.google.com/a/thumbtack.net/spreadsheet/ccc?key=0AvuuGoU4GQTkdGp6UU9 1 https://jira.corp.ooyala.com/ 1 http://lasership.com/track/1LS716000162468 1 http://vk.com/kurajbambey_ru 1 https://app.asana.com/0/5342359612711/5413807008821 1 http://www.ib.bioninja.com.au/options/option-e-neurobiology-and-2/e1-stimulus-an 1 http://grooveshark.com/#!/album/Random+Access+Memories/8814557 1 http://movies.netflix.com/WiPlayer?movieid=70136119&trkid=7100597 1 http://www.unrealengine.com/html5/ 1 http://www.theatlantic.com/technology/archive/2013/05/so-this-is-how-it-begins-g 1 https://www.google.com/search?q=creating+a+windows+8+install+usb&ie=utf-8&oe=utf 1 http://blogs.valvesoftware.com/abrash/
Assigning to peterv since he is working a similar bug with a test case: https://bugzilla.mozilla.org/show_bug.cgi?id=869027#c22.
Assignee: nobody → peterv
Peter - any update on this?
Flags: needinfo?(peterv)
No update beyond comment 22.
Flags: needinfo?(peterv)
Crash Signature: , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] → , JS::Handle<__int64> const&) ] [@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] [@ js::CompartmentChecker::check(JSObject*)]
Another fix for this landed on 6/5, so this may be fixed now. I don't see any crashes for JS_HasPropertyById(JSContext*, JSObject*, int, int*) in the 6/6 build.
Fully fixed by bug 871849.
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox23: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
It has reappeared at a lower volume since 24.0a1/20130609 and 23.0a2/20130613. The regression range might be: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=6f7c753b3abc&tochange=40c9d5acd1b7 More reports at: https://crash-stats.mozilla.com/report/list?signature=JS_HasPropertyById%28JSContext*%2C+JSObject*%2C+int%2C+int*%29
Status: RESOLVED → REOPENED
status-firefox23: fixed → affected
status-firefox24: --- → affected
Resolution: FIXED → ---
I'd prefer a new bug to be filed as there was definitely an issue fixed here. If we don't go to a new bug for the remainder issue, we'll have to play flag ballet and probably remove tracking, possibly also topcrash, as now this is a much lower level of crashes.
(In reply to Robert Kaiser (:kairo@mozilla.com) [away until early June] from comment #32) > I'd prefer a new bug to be filed as there was definitely an issue fixed > here. This bug has no patch, applies to the same versions as initially reported, and has the same stack trace (especially mozilla::dom::HTMLDocumentBinding::DOMProxyHandler::get) as in comment 1. > possibly also topcrash It's #10 top browser crasher in 23.0a2 over the last three days.
(In reply to Robert Kaiser (:kairo@mozilla.com) [away until early June] from comment #34) > Actually, for me it's far out of topcrash range if I look at stats for > builds from the last three days: The Socorro-crashstats prod server is wrong. See https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/23.0a2/3/browser
This does seem to have gone down a lot. There's still a crash remaining but we don't have steps to reproduce. I've been poking at this a bit, looking at crashdumps etc but for now there's not much more I can do about it.
(In reply to Peter Van der Beken [:peterv] from comment #37) > This does seem to have gone down a lot. There's still a crash remaining but > we don't have steps to reproduce. I've been poking at this a bit, looking at > crashdumps etc but for now there's not much more I can do about it. I used to hit this crash a few times per day, but since bug 871849 was fixed, I have not seen a single instance of this crash. It could be that the remaining crash is a different bug, caused by something else...
The second spike in comment 31 is very low and it's above #300 crasher in 23.0b1.
tracking-firefox23: + → ?
Keywords: topcrash
[@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] is currently the #8 topcrash on Nightly though I'm not seeing the other signatures in this bug reported. Also this is only #38 in Aurora and non-existent on Beta/Release. Please advise if this is the same bug or if I should file a new one. More reports here: https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-11-12&signature=js%3A%3ACompartmentChecker%3A%3Afail%28JSCompartment*%2C+JSCompartment*%29&version=Firefox%3A28.0a1
The CompartmentChecker signature is very generic, so two separate crash spikes with that signature are unlikely to be related. Tracy Walker filed bug 937191 for the latest spike, and there's a patch waiting to land, so hopefully it will go down again.
I'm updating the topcrash info for this here, since this bug is still open and it's #1 for Firefox 28.0a1 right now. I can't see bug 937191. 7 day report: #1 with 3611 crashes. 350 crashes for the 2013111603 build. 402 crashes for the 2013111703 build.
Yeah, unfortunately the patch got backed out there (well, bug 936327, but close enough). This new problem is as a result of Kyle's patch, so let's reassign to him. ;)
Assignee: peterv → khuey
My earlier comment was about js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) For Firefox 27, that crash signature is at #31 with 41 crashes. In Firefox 26, there were only 2 crashes for that signature so I think maybe I shouldn't add FF26 tracking flags.
status-firefox27: --- → affected
status-firefox28: --- → affected
tracking-firefox27: --- → ?
tracking-firefox28: --- → ?
Keywords: topcrash-win
It would be nice to track a new bug in a new bug. Mashing things together is a little confusing. For instance, I think this doesn't have anything to do with JS_HasPropertyById.
Let's leave this bug here to the original issue, the new topcrash is/was bug 936327 (which just landed). Andrew, does comment #43 mean the original issue here should also be fixed by bug 936327 or is that still different?
status-firefox27: affected → ---
status-firefox28: affected → ---
tracking-firefox27: ? → ---
tracking-firefox28: ? → ---
Flags: needinfo?(continuation)
Keywords: topcrash-win
The original issue was fixed by bug 871849, per comment 30. Or at least, mostly fixed.
Flags: needinfo?(continuation)
Whatever isn't fixed should be a new bug report.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) signature shows a high URL correlation to GMail and Google+ URLs. Some other URLs for the various signatures: js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<__int64> >(JSContext*, JS::Handle<JSObject*> const&, JS::Handle<__int64> const&) 5 about:blank 2 about:addons 1 http://uspstrackingservice.com 1 http://www.kissanimeworld.com 1 http://www.appsandapks.com 1 https://www.google.com/search?q=R%E3%80%80%E6%96%87%E5%AD%97%E5%88%97%E3%80%80%E 1 http://www.tekken7game.com 1 http://www.techontop.com 1 http://www.doctordarkcircles.com 1 http://www.prismaonandroid.com 1 https://www.facebook.com 1 http://www.automaticcallrecorderpro.com
js::CompartmentChecker::fail(JSCompartment*, JSCompartment*) signature shows a high URL correlation to GMail and Google+ URLs. Some other URLs for the various signatures: js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<__int64> >(JSContext*, JS::Handle<JSObject*> const&, JS::Handle<__int64> const&) 5 about:blank 2 about:addons https://www.facebook.com/Fire-Pit-203222307131272/ https://best-fire-pit.harleywives.com/
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.