[e10s] Tab crashes on certain page with Adblock Plus+ Tofu Filter if browser.tabs.remote.autostart = true

VERIFIED FIXED in Firefox 35

Status

()

--
critical
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: alice0775, Assigned: billm)

Tracking

(Blocks: 1 bug, {addon-compat, crash, regression})

33 Branch
mozilla34
x86_64
Windows 7
addon-compat, crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox34 affected, firefox35 verified)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/0894d2cdb16d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140720030203

Tab crashes when browser.tabs.remote.autostart = true.
However,
Tab does not crash on e10s window(browser.tabs.remote.autostart = false).

Steps To Reproduce:
1. Make sure e10s, set browser.tabs.remote.autostart = true and restart
2. Install Adblock Plus development build
   https://adblockplus.org/devbuilds/adblockplus/00latest.xpi
3. Subscribe 豆腐フィルタ(Tofu Filter) which is a famous filter for Japanese site.
   Open http://tofukko.r.ribbon.to/abp.html
   Click a link of "フィルタを購読する"
4. Open a certain web page http://blogs.yahoo.co.jp/alice0775

Actual Results:
Tab crashed

Expected Results:
Tab should not crash
(Reporter)

Comment 1

4 years ago
Created attachment 8459492 [details]
tofu_filter.txt
(Reporter)

Comment 2

4 years ago
Tested with Adblock Plus 2.6.3.3849
(Reporter)

Comment 3

4 years ago
Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/31c5d0a5115d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140715053734
Bad:
https://hg.mozilla.org/mozilla-central/rev/d2d56f9066bf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140715055935
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31c5d0a5115d&tochange=d2d56f9066bf


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c93d64f6a76a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140714104309
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/692a0f99d09d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140714105411
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c93d64f6a76a&tochange=692a0f99d09d

Regressed by:
692a0f99d09d	Mike Conley — Bug 1002354 - Proxy nsIScreenManager and nsIScreen's from the child process to the parent process, with caching. r=roc,jimm,smichaud,snorp. Changes to nsIScreen and nsIScreenManager were reviewed by roc. Changes to dom/ipc were reviewed by jimm. Changes to gfx/src/nsDeviceContext.cpp were reviewed by roc. Changes to widget/android were reviewed by snorp. Changes to widget/cocoa were reviewed by smichaud. Changes to widget/gtk were reviewed by roc. Changes to widget/windows were reviewed by jimm. Changes to widget/xpwidgets were reviewed by roc.
Blocks: 1002354
Severity: normal → critical
Keywords: crash, regression
Interesting - do you have a crash report you can attach too, Alice? Tab crashes should be listed in about:crashes too.
Flags: needinfo?(alice0775)
Alice: does this crash only happen when using the Tofu Filter?
tracking-e10s: --- → ?
Keywords: addon-compat
(Reporter)

Comment 6

4 years ago
(In reply to Mike Conley (:mconley) from comment #4)
> Interesting - do you have a crash report you can attach too, Alice? Tab
> crashes should be listed in about:crashes too.

bp-c56bfe23-187e-4e61-8584-13a292140722
Flags: needinfo?(alice0775)
(Reporter)

Comment 7

4 years ago
(In reply to Chris Peterson (:cpeterson) from comment #5)
> Alice: does this crash only happen when using the Tofu Filter?

Tab also crashes with "ABP Japanese Filters (日本語)"

Steps to add the filter:
1. Open "Filter preferences…" (Ctrl+Shift+F)
2. Click [Add filter subscription…]
3. Click textlink "Add a different subscription"
3. Select "ABP Japanese Filters (日本語)"
5. Click [Add subscription] button
(Reporter)

Updated

4 years ago
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::ipc::MessageChannel::DebugAbort(char const*, int, char const*, char const*, bool) | mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*)]

Comment 8

4 years ago
(In reply to Alice0775 White from comment #6)
> (In reply to Mike Conley (:mconley) from comment #4)
> > Interesting - do you have a crash report you can attach too, Alice? Tab
> > crashes should be listed in about:crashes too.
> 
> bp-c56bfe23-187e-4e61-8584-13a292140722

ProcessPendingUrgentRequest() is on the stack, and we're trying to send a sync request for a screen.

I've run into this in another case with some gfx related urgent messages, I'm not sure how we work around this.
Blocks: 905436

Comment 9

4 years ago
Not just on Japanese filters, does it on this site for me with ABP installed too:

http://www.explosm.net/comics/new/
(Reporter)

Updated

4 years ago
See Also: → bug 1021053
(Reporter)

Comment 10

4 years ago
(In reply to Grant from comment #9)
> Not just on Japanese filters, does it on this site for me with ABP installed
> too:
> 
> http://www.explosm.net/comics/new/

Regression range is different. I filed separate Bug 1042587 .
tracking-e10s: ? → +
Assignee: nobody → wmccloskey
Duplicate of this bug: 1045102
Attachment #8465809 - Flags: review?(jmathies)
Comment on attachment 8465809 [details] [diff] [review]
rpc-for-screen

Review of attachment 8465809 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good to me. It's a shame that we have to change all of the method signatures like this, when we should probably just change the message type in ipdl, but whatever.

Thanks!
Attachment #8465809 - Flags: review?(mconley) → review+

Comment 14

4 years ago
Comment on attachment 8465809 [details] [diff] [review]
rpc-for-screen

after a discussion on how this fixes this crash - rpc is allowed to make out calls from within processing of urgent message in the child.
Attachment #8465809 - Flags: review?(jmathies) → review+
Blocks: 1047563
https://hg.mozilla.org/mozilla-central/rev/9f4d1a20f5b3
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
QA Whiteboard: [qa+]
Reproduced the initial issue on old Nightly (2014-07-21), verified that the issue is fixed on latest Nightly 35.0a1. Since target milestone is set to 34 I will set the tracking flag as affected because this issue still exists in Aurora 34.0a2.
Status: RESOLVED → VERIFIED
status-firefox34: --- → affected
status-firefox35: --- → verified
You need to log in before you can comment on or make changes to this bug.