Please see Bug 397178#c2. Can we please bring the NSS tag up to date? Also, how do we ensure that this doesn't happen in the future?

(In reply to comment #0) > Also, how do we ensure that this doesn't happen in the future? Ensure that what doesn't happen in the future? The NSS team has decided to have trunk Mozilla builds use tagged "snapshots" of NSS HEAD rather than always use HEAD, so this kind of delay in having fixes to NSS affect Mozilla builds is expected.

Marcia just stopped by. 1) If this bug is caused by the wrong timestamp/version of NSS code being used in the nightly builds, this seems scary to me. Should this be a 1.9blocker? 2) What should we do to fix this? I dont understand what tagged snapshots the build *should* be using, and how are we supposed to know what newer "blessed" tagged snapshot to move to? 3) Should this be reassigned to mozilla.org/Build&Release?

This affects Windows as well, changing Hardware and Version to all.

(In reply to comment #2) > Marcia just stopped by. > > 1) If this bug is caused by the wrong timestamp/version of NSS code being used > in the nightly builds, this seems scary to me. Should this be a 1.9blocker? It's not using "the wrong" timestamp/version. It's just using one from before the fix for bug 397178 was landed. > 2) What should we do to fix this? I dont understand what tagged snapshots the > build *should* be using, and how are we supposed to know what newer "blessed" > tagged snapshot to move to? The build team shouldn't have to worry about this bug, as far as I know. NSS/Firefox developers are responsible for tagging snapshots of NSS for use on the Mozilla trunk, and checking in the appropriate change to client.mk.

Yes, NSS developers tag NSS for use in Firefox trunk, on request. Firefox developers change the tag in whatever makefile it is in.

(In reply to comment #4) > (In reply to comment #2) > > Marcia just stopped by. > > > > 1) If this bug is caused by the wrong timestamp/version of NSS code being used > > in the nightly builds, this seems scary to me. Should this be a 1.9blocker? > > It's not using "the wrong" timestamp/version. It's just using one from before > the fix for bug 397178 was landed. But Marcia was testing a build from 22sep2007, and the NSS code fix was supposedly landed in 13jul2007. Thats a two month lag... is the client.mk correct? > > 2) What should we do to fix this? I dont understand what tagged snapshots the > > build *should* be using, and how are we supposed to know what newer "blessed" > > tagged snapshot to move to? > > The build team shouldn't have to worry about this bug, as far as I know. > NSS/Firefox developers are responsible for tagging snapshots of NSS for use on > the Mozilla trunk, and checking in the appropriate change to client.mk. Is this the correct component for this bug?

(In reply to comment #6) > But Marcia was testing a build from 22sep2007, and the NSS code fix was > supposedly landed in 13jul2007. Thats a two month lag... is the client.mk > correct? Someone from the NSS team will have to answer this question. We currently seem to be using the NSS_3_12_ALPHA1B tag ( http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=1.349&mark=410#403 ). Bug 233932 was fixed by revision 1.8 of lginit.c. The NSS_3_12_ALPHA1B tag is on revision 1.7 of lginit.c. I don't understand NSS milestones - I would expect a bug with a target milestone of 3.11.8 to be included in a tag named NSS_3_12_ALPHA1B, but that doesn't seem to be the case. Is that expected? > Is this the correct component for this bug? Assuming that all we need is an updated tag, yes. It should probably be assigned from someone on the NSS team to create a new tag. Kai or Nelson?

Gavin confirmed that the snapshot currently used by Firefox trunk does not yet contain the fix. Bob is trying to get a new snapshot by the end of the week. (In reply to comment #7) > I don't understand NSS milestones - I would expect a bug with a target > milestone of 3.11.8 to be included in a tag named NSS_3_12_ALPHA1B, but that > doesn't seem to be the case. Is that expected? Sorry, I have to ask what exactly you mean by this. 3.11.8 is a release based on the stable branch. 3.12.alpha is based on NSS trunk Depending on the timestamp of the snapshots fixes may only be in one of the two.

(In reply to comment #8) > 3.11.8 is a release based on the stable branch. > > 3.12.alpha is based on NSS trunk > > Depending on the timestamp of the snapshots fixes may only be in one of the > two. Ok. I didn't know that 3.11 and 3.12 were based on different branches, and I wasn't sure how the NSS team uses target milestones (whether it always tracks the trunk, or "earliest version fixed", etc).

(In reply to comment #9) > I > wasn't sure how the NSS team uses target milestones (whether it always tracks > the trunk, or "earliest version fixed", etc). If a fix was landed on trunk only, then the target milestone will be set to the next version based on the trunk (currently 3.12) If a fix got backported to the stable branch, the target milestone will be set to the first branch version that will contain the fix.

Not sure if I'm following all the twists between bug#397296, bug#397178 and bug#397480, so let me try to summarize. QA are hitting crashes when resetting password in recent 1.9/trunk nightlies. These crashes are known issues in NSS code and already fixed. However the fixed NSS code is not being picked up in 1.9/trunk builds. The version of NSS being used in Firefox trunk is from at least before 13july2007, and does not have any NSS fixes since then. Therefore, QA are still hitting the bug. I believe any other NSS fixes since 13july2007 are also not visible in 1.9/trunk builds. Its possible that this is expected behavior, and I just dont have enough background to understand. However, this seems like a serious problem with 1.9/trunk builds that I think should be a 1.9blocker, hence nominating.

Firefox releases always come from NSS release points, so of course... perhaps we should add that to some release checklist though.

Seems that "blocking‑firefox3" isnt enough, adding "Target Milestone Firefox3 M9" while in meeting with Damon.

This patch: - updates the NSPR tag to a newer snapshot - updates the NSS tag to alpha 2 - pulls in a small int type change from dependency bug 388118 (so we don't break the build) We tested this combination on Linux, Mac and Windows.

Comment on attachment 284498 [details] [diff] [review] Patch v1 r=mconnor

Checked in, marking fixed.

verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre. I no longer crash when trying to reset my Master Password.