Closed Bug 1271019 Opened 4 years ago Closed 4 years ago
_CRASH() in ns XPCWrapped JS::Call Method due to being called on the Cache I/O thread (off main thread), starting 2016-05-06
This bug was filed from the Socorro interface and is report bp-97b6eed8-f842-4afd-b1d5-68df32160506. ============================================================= A new spike in crashes started in May 6 builds on mozilla-central. Regression window is most likely: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=369a5ee3a2880a4a98df3a00bf3db8d8f36b181b&tochange=25d777f7efb357fc5478251913548521986abaa0 unless we somehow managed to avoid any crashes on May 5 (very unlikely, given the numbers on the 6th). Query at: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=nightly&date=%3E%3D2016-05-01&signature=nsXPCWrappedJS%3A%3ACallMethod The crash is because XPCWrappedJS has a MOZ_CRASH() if it's called off the main thread, and it's being called on the I/O thread. This is the #1 topcrash for May 6 nightlies.
> This is the #1 topcrash for May 6 nightlies. May 7 and 8, too. Honza, can you please investigate?
Apparently the URI is a JS implementation and we try to do something with it on non-main thread. Have we added some new code recently which is using HTTP cache directly and is also using JS implemented uris? Or is some of the extensions you have installed doing this? Have there been recently (at the regression dates) an update of any of them?
Assignee: nobody → honzab.moz
Flags: needinfo?(honzab.moz) → needinfo?(dbaron)
I haven't hit this crash myself; I saw it looking at crash-stats. You could look at the extensions info in the crash reports to find out the information you want.
FYI, there's a 100% correlation with the Yandex.Bar addon . The addon was last updated in April, but the crash only started appearing in the 20160506030222 nightly build (regression range )  https://addons.mozilla.org/addon/3495  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=369a5ee3a2880a4a98df3a00bf3db8d8f36b181b&tochange=25d777f7efb357fc5478251913548521986abaa0
FWIW, if it turns out to be something that needs to be fixed in the addon, I have contacts at Yandex.
(In reply to Jim Chen [:jchen] [:darchons] from comment #4) > FYI, there's a 100% correlation with the Yandex.Bar addon . The addon was > last updated in April, but the crash only started appearing in the > 20160506030222 nightly build (regression range ) > >  https://addons.mozilla.org/addon/3495 >  > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=369a5ee3a2880a4a98df3a00bf3db8d8f36b181b&tochange=25d7 > 77f7efb357fc5478251913548521986abaa0 Thanks for this info. Definitely, yandex extension is accessing cache API directly. Apparently we (Firefox/Gecko) either introduced a new schema that uses JS implemented nsIURI and yandex is getting hands on it, or it is interaction with even another add-on, which does it. Anyway, to save the long path of figuring this out, I will simply fix it in the cache code. It was a time-bomb anyway.
Status: NEW → ASSIGNED
- CacheEntry::mURI changed from nsCOMPtr<nsIURI> to nsCString which holds asciiSpec - on most places we are using overload of static CacheEntry::HashingKey whom 3rd arg can be either nsIURI or asciispec, so no need to change - no need to keep reference to the release thread to drop the mURI ref on any longer (as a benefit, this could potentially fix bug 1271699) - some small cleanup of CacheEntry ctor/dtor https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ff0f2df8447
Attachment #8751749 - Flags: review?(michal.novotny)
Attachment #8751749 - Flags: review?(michal.novotny) → review+
You need to log in before you can comment on or make changes to this bug.