Closed
Bug 869027
Opened 8 years ago
Closed 7 years ago
crash in JS_HasPropertyById
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla24
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.
![]() |
||
Updated•8 years ago
|
Assignee: nobody → general
Component: Editor → JavaScript Engine
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
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
Comment 3•8 years ago
|
||
Dupe of bug 869038?
![]() |
||
Comment 4•8 years ago
|
||
Seems pretty likely...
Reporter | ||
Comment 5•8 years ago
|
||
Alright, let me know if you need anything from me, I can't see that issue.
Updated•8 years ago
|
Crash Signature: , JS::Handle<__int64> const&) ]
[@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] → , JS::Handle<__int64> const&) ]
[@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)]
[@ SearchTable ]
[@ nsIFrame::Preserves3D() ]
Comment 6•8 years ago
|
||
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*)]
Comment 7•8 years ago
|
||
I have gotten three related crashes the last three times when I've shut down or restarted my Nightly: https://crash-stats.mozilla.com/report/index/bp-1829e272-b9d1-42e6-ac73-111102130507 https://crash-stats.mozilla.com/report/index/bp-ca76bfc2-1e17-4c82-a8e4-62a662130507 https://crash-stats.mozilla.com/report/index/bp-73370918-7121-4c8e-a0bf-214692130508
Comment 8•8 years ago
|
||
There are about 500 crashes per build.
![]() |
||
Comment 9•8 years ago
|
||
(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.
Comment 10•8 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9) > which has a fix in inbound at this time. Thanks for info!
Updated•8 years ago
|
Comment 11•8 years ago
|
||
(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.
![]() |
||
Comment 12•8 years ago
|
||
(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.
Comment 13•8 years ago
|
||
Nevertheless, the volume is lower than before the fix of bug 869038.
Severity: blocker → critical
Comment 14•8 years ago
|
||
(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
![]() |
||
Comment 15•8 years ago
|
||
Yes, we'll need the JS team to look into this one.
Flags: needinfo?(nihsanullah)
Comment 16•8 years ago
|
||
Weird, there's a CCW on the stack, so we should have entered the right compartment there.
Comment 17•8 years ago
|
||
(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.
Comment 18•8 years ago
|
||
> 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?
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.
![]() |
||
Comment 21•8 years ago
|
||
Peter, you were saying something about issues with HTMLDocument expando tracing?
Flags: needinfo?(peterv)
Comment 22•8 years ago
|
||
(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)
Comment 23•8 years ago
|
||
I guess we'll blame this on DOM for now.
Assignee: general → nobody
Component: JavaScript Engine → DOM
Flags: needinfo?(nihsanullah)
![]() |
||
Comment 24•8 years ago
|
||
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.
Comment 25•8 years ago
|
||
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/
Comment 26•8 years ago
|
||
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
Updated•8 years ago
|
Crash Signature: , JS::Handle<__int64> const&) ]
[@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)] → , JS::Handle<__int64> const&) ]
[@ js::CompartmentChecker::fail(JSCompartment*, JSCompartment*)]
[@ js::CompartmentChecker::check(JSObject*)]
Comment 29•8 years ago
|
||
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.
Comment 30•8 years ago
|
||
Fully fixed by bug 871849.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Comment 31•8 years ago
|
||
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
![]() |
||
Comment 32•8 years ago
|
||
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.
Comment 33•8 years ago
|
||
(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.
![]() |
||
Comment 34•8 years ago
|
||
Actually, for me it's far out of topcrash range if I look at stats for builds from the last three days: https://crash-stats-django.mozilla.org/topcrasher/products/Firefox/versions/23.0a2/date_range_type/build/crash_type/browser/os_name/None?days=3 Same If I look at builds from the last 7 days, btw: https://crash-stats-django.mozilla.org/topcrasher/products/Firefox/versions/23.0a2/date_range_type/build/crash_type/browser/os_name/None?days=7
Comment 35•8 years ago
|
||
(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
![]() |
||
Comment 36•8 years ago
|
||
No, socorro-crashstats is not wrong. PHP shows the same in by-build mode: https://crash-stats.mozilla.com/topcrasher/by_build_date/Firefox/23.0a2/3/browser and https://crash-stats.mozilla.com/topcrasher/by_build_date/Firefox/23.0a2/7/browser
Comment 37•8 years ago
|
||
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.
Comment 38•8 years ago
|
||
(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...
Comment 39•8 years ago
|
||
The second spike in comment 31 is very low and it's above #300 crasher in 23.0b1.
Keywords: topcrash
Updated•8 years ago
|
Comment 40•7 years ago
|
||
[@ 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
Comment 41•7 years ago
|
||
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.
Comment 43•7 years ago
|
||
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
Comment 45•7 years ago
|
||
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.
![]() |
||
Comment 46•7 years ago
|
||
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
Comment 47•7 years ago
|
||
The original issue was fixed by bug 871849, per comment 30. Or at least, mostly fixed.
Flags: needinfo?(continuation)
Assignee | ||
Comment 48•7 years ago
|
||
So is this fixed now?
Comment 49•7 years ago
|
||
Whatever isn't fixed should be a new bug report.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → FIXED
Comment 50•4 years ago
|
||
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
Comment hidden (spam) |
Comment 52•3 years ago
|
||
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/
Comment hidden (spam) |
Comment hidden (spam) |
Updated•2 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•