Closed
Bug 693228
Opened 12 years ago
Closed 11 years ago
Closing a tab with Flash content, then opening a tab with Flash content, hangs the plugin-container/Firefox
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
3.13.1
People
(Reporter: sparky, Assigned: rrelyea)
References
Details
Crash Data
Attachments
(2 files)
593 bytes,
patch
|
wtc
:
review+
briansmith
:
superreview+
|
Details | Diff | Splinter Review |
2.53 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
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•12 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
Updated•12 years ago
|
Component: General → Plug-ins
QA Contact: general → plugins
Reporter | ||
Comment 2•12 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•12 years ago
|
||
This is not the only regression caused by the NSS upgrade, assuming your bisection is accurate.
Blocks: 669061
Comment 4•12 years ago
|
||
Kai, are you able to reproduce this? Do you think you could track down the cause?
Reporter | ||
Comment 5•12 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
Comment 6•12 years ago
|
||
This is a possible regression in NSS 3.13.
Comment 7•12 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•12 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•12 years ago
|
||
wtc please review this patch.
Attachment #567642 -
Flags: superreview?(bsmith)
Attachment #567642 -
Flags: review?(wtc)
Assignee | ||
Comment 10•12 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•12 years ago
|
||
clearly confirmed, setting state appropriately.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 12•12 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 13•11 years ago
|
||
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•11 years ago
|
||
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•11 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•11 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•11 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•11 years ago
|
||
with wtc's checkin, we can now close this.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 19•11 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.
Description
•