Closed Bug 693228 Opened 13 years ago Closed 13 years ago

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


(NSS :: Libraries, defect, P1)



(Not tracked)



(Reporter: sparky, Assigned: rrelyea)



Crash Data


(2 files)

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:

2011-10-08-03-09-46 Linux 64 build hangs:

Regression window:
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
Alright, I did some testing on the tinderbox builds. Since there was a large mozilla-inbound merge, I started there:

That lead me back to mozilla-central:

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

I am now thoroughly confused by this regression.
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?
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.
Crash Signature: [@ hang | ]
This is a possible regression in NSS 3.13.
Bob, the crash stack in comment 5 is in new code you added to nss_Init
for bug 679524:

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
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?
wtc please review this patch.
Attachment #567642 - Flags: superreview?(bsmith)
Attachment #567642 - Flags: review?(wtc)
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.

clearly confirmed, setting state appropriately.
Ever confirmed: true
Comment on attachment 567642 [details] [diff] [review]
decrement nssInInit counter in the error path as well as the success path.

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]:

Attachment #567642 - Flags: superreview?(bsmith) → superreview+
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)
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
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 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
with wtc's checkin, we can now close this.
Closed: 13 years ago
Resolution: --- → FIXED
The bug fix landed in mozilla-central at 02:35:01 -0700 (US Pacific
Daylight Time) today:

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.