Closing a tab with Flash content, then opening a tab with Flash content, hangs the plugin-container/Firefox

RESOLVED FIXED in 3.13.1

Status

NSS
Libraries
P1
critical
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Matthew Turnbull [Bluefang], Assigned: Robert Relyea)

Tracking

3.13
3.13.1
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Steps to reproduce:
1. Open a page with Flash content (i.e. YouTube)
2. Close the tab
3. Re-open the tab, or navigate to a new page with Flash content

Expected results:
The page and Flash content loads

Actual results:
Firefox hangs until the plugin-container process is killed or IPC child timeout is reached (45 seconds).


This looks to be IPC related because the problem goes away when dom.ipc.plugins.enabled is set to false.

This also does not look to be related to the recent Flash 11 release, as I tried using a older version of Flash and it still hung.

2011-10-07-03-12-27 Linux 64 build ok:
http://hg.mozilla.org/mozilla-central/rev/c3a50afc2243

2011-10-08-03-09-46 Linux 64 build hangs:
http://hg.mozilla.org/mozilla-central/rev/6c780dcb4b99

Regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c3a50afc2243&tochange=6c780dcb4b99

Comment 1

7 years ago
Let's move this to General right now, because I don't see anything in that range that jumps out at me as being specifically about plugins.
Component: IPC → General
QA Contact: ipc → general
Component: General → Plug-ins
QA Contact: general → plugins
(Reporter)

Comment 2

7 years ago
Alright, I did some testing on the tinderbox builds. Since there was a large mozilla-inbound merge, I started there:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d85e3d033bf1&tochange=fd0f0a12be74

That lead me back to mozilla-central:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35954e6f3167&tochange=8f011395145e

tinderbox-builds/mozilla-central-linux64 build 1318014465 -> build 1318023804

I am now thoroughly confused by this regression.

Comment 3

7 years ago
This is not the only regression caused by the NSS upgrade, assuming your bisection is accurate.
Blocks: 669061
Kai, are you able to reproduce this? Do you think you could track down the cause?
(Reporter)

Comment 5

7 years ago
Yeah, I saw from poking around some other bugs. I was just surprised it was NSS related. I didn't expect that.

Anyways, I finally got a plugin crash/hang report for this. Hopefully it helps.
https://crash-stats.mozilla.com/report/index/bp-a24bb3f0-11c0-4e62-bc3d-4c37a2111015

Updated

7 years ago
Crash Signature: [@ hang | libpthread-2.12.2.so@0xb5ac ]
This is a possible regression in NSS 3.13.

Comment 7

7 years ago
Bob, the crash stack in comment 5 is in new code you added to nss_Init
for bug 679524:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/nss/nssinit.c&rev=1.112&mark=594#579

Could you take a look at it?  Thanks.
Assignee: nobody → rrelyea
Component: Plug-ins → Libraries
Product: Core → NSS
QA Contact: plugins → libraries
Target Milestone: --- → 3.13.1
Version: Trunk → 3.13
(Assignee)

Comment 8

7 years ago
Ah, this isn't a crash, it's a hang...

I think there may be a problem in the error path where nssInInit is not getting decremented in the error case. Is SSL involved in the website, perchance?
(Assignee)

Comment 9

7 years ago
Created attachment 567642 [details] [diff] [review]
decrement nssInInit counter in the error path as well as the success path.

wtc please review this patch.
Attachment #567642 - Flags: superreview?(bsmith)
Attachment #567642 - Flags: review?(wtc)
(Assignee)

Comment 10

7 years ago
General comments. I could not reproduce this bug as stated, but there is enough information that I could induce a failure. If I create a new profile, then turn off access to my .db files in the profile, then the nightly build will hang on startup. With this patch, it will give the 'can't initialize security warning'.

In order to reproduce this bug, I believe you need to somehow have firefox configured so it does not initialize NSS at startup, and flash is the first user of NSS. Flash also has to try to open NSS with an invalid database (or some other mechanism to induce NSS initialization failure).

It looks to me that flash should probably be initializing NSS with the NSS_ContextInit calls, but that would not have prevented this problem. We probably should let adobe know so that future flash pluggins use the more library friendly initialization scheme.

bob
(Assignee)

Comment 11

7 years ago
clearly confirmed, setting state appropriately.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 12

7 years ago
Comment on attachment 567642 [details] [diff] [review]
decrement nssInInit counter in the error path as well as the success path.

r=wtc.
Attachment #567642 - Flags: review?(wtc) → review+
Comment on attachment 567642 [details] [diff] [review]
decrement nssInInit counter in the error path as well as the success path.

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

sr=bsmith
Attachment #567642 - Flags: superreview?(bsmith) → superreview+

Comment 14

7 years ago
Created attachment 567752 [details] [diff] [review]
nss_doLockInit and PR_CallOnce return PRStatus, not SECStatus

Bob, you can check this in along with your patch, or I can
check this in later.

I made these cleanup changes while reviewing your patch for
bug 679524.
Attachment #567752 - Flags: review?(rrelyea)
(Assignee)

Comment 15

7 years ago
Go ahead and check it in after mine...

Checking in nssinit.c;
/cvsroot/mozilla/security/nss/lib/nss/nssinit.c,v  <--  nssinit.c
new revision: 1.113; previous revision: 1.112
done
(Assignee)

Comment 16

7 years ago
Comment on attachment 567752 [details] [diff] [review]
nss_doLockInit and PR_CallOnce return PRStatus, not SECStatus

oops forgot to r+ wtc's patch...
Attachment #567752 - Flags: review?(rrelyea) → review+

Comment 17

7 years ago
Comment on attachment 567752 [details] [diff] [review]
nss_doLockInit and PR_CallOnce return PRStatus, not SECStatus

Patch checked in on the NSS trunk (NSS 3.13.1).

Checking in nssinit.c;
/cvsroot/mozilla/security/nss/lib/nss/nssinit.c,v  <--  nssinit.c
new revision: 1.114; previous revision: 1.113
done
(Assignee)

Comment 18

7 years ago
with wtc's checkin, we can now close this.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 19

7 years ago
The bug fix landed in mozilla-central at 02:35:01 -0700 (US Pacific
Daylight Time) today:
http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=609372752255

Bluefang: could you verify the bug fix with a Firefox nightly build
that contains the fix?  Thanks.
Severity: normal → critical
Priority: -- → P1
You need to log in before you can comment on or make changes to this bug.