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

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Matthew Turnbull [Bluefang]]

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

[Josh Matthews [:jdm]]

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.

Comment 2

[Matthew Turnbull [Bluefang]]

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

[Josh Matthews [:jdm]]

This is not the only regression caused by the NSS upgrade, assuming your bisection is accurate.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Kai, are you able to reproduce this? Do you think you could track down the cause?

Comment 5

[Matthew Turnbull [Bluefang]]

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

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

This is a possible regression in NSS 3.13.

Comment 7

[Wan-Teh Chang]

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.

Comment 8

[Robert Relyea]

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?

Comment 9

[Robert Relyea]

Attachment: decrement nssInInit counter in the error path as well as the success path.

wtc please review this patch.

Comment 10

[Robert Relyea]

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

Comment 11

[Robert Relyea]

clearly confirmed, setting state appropriately.

Comment 12

[Wan-Teh Chang]

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

r=wtc.

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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

Comment 14

[Wan-Teh Chang]

Attachment: 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.

Comment 15

[Robert Relyea]

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

Comment 16

[Robert Relyea]

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

oops forgot to r+ wtc's patch...

Comment 17

[Wan-Teh Chang]

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

Comment 18

[Robert Relyea]

with wtc's checkin, we can now close this.

Comment 19

[Wan-Teh Chang]

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.