593 bytes, patch
|Details | Diff | Splinter Review|
2.53 KB, patch
|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
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: 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.
This is not the only regression caused by the NSS upgrade, assuming your bisection is accurate.
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. https://crash-stats.mozilla.com/report/index/bp-a24bb3f0-11c0-4e62-bc3d-4c37a2111015
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: 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
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?
Created attachment 567642 [details] [diff] [review] decrement nssInInit counter in the error path as well as the success path. wtc please review this patch.
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
clearly confirmed, setting state appropriately.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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+
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)
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 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 done
with wtc's checkin, we can now close this.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
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.