Closed Bug 133584 Opened 23 years ago Closed 22 years ago

SECMOD_DestroyModule fails during NSS_Shutdown

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: wtc, Assigned: rrelyea)

References

Details

(Keywords: qawanted, Whiteboard: [adt2 RTM] [05/31])

Attachments

(7 files)

patch to securit/nss/lib to fix slot reference leaks which prevents shutdown
20.30 KB, patch
wtc
: review+
Details | Diff | Splinter Review
patch for security/nss/cmd to fix slot leaks in our test programs .
15.05 KB, patch
Details | Diff | Splinter Review
Incremental patch (on top of attachment 78847): need to free free_slot on error return
625 bytes, patch
Details | Diff | Splinter Review
refcount log (gzipped)
7.28 KB, application/octet-stream
Details
refcount leak tree
24.26 KB, text/plain
Details
patch to security/nss/lib on MOZILLA_1_0_0_BRANCH
22.19 KB, patch
Details | Diff | Splinter Review
patch to security/nss/lib on NSS_3_4_BRANCH
20.85 KB, patch
Details | Diff | Splinter Review 
This bug corresponds to the PSM bug 125561.

Mozilla calls NSS_Shutdown to close one user profile and
then reinitializes NSS with another user profile.

It is reported that during NSS_Shutdown, SECMOD_DestroyModule
fails, and so the module is not being unloaded.
Blocks: 125561
Priority: -- → P1
Summary: SECMOD_DestroyModule fails in NSS_Shutdown → SECMOD_DestroyModule fails during NSS_Shutdown
Target Milestone: --- → 3.4.1
Ian, could you take a look at this bug?  Thanks.
Assignee: relyea → ian.mcgreer
This is not neccesarily an NSS bug.  As I mentioned before, I have verified that
strsclnt shuts down cleanly, as does certutil.  This behavior can be caused by a
leaked slot reference, and the leak could very well be in PSM.  I believe a PSM
engineer should debug a session, trapping all calls to PK11_ReferenceSlot() and
PK11_FreeSlot(), to see where the leak occurs.  It could be as simple as a call
to PK11_GetInternalKeySlot() not being matched with a call to PK11_FreeSlot().

If I am wrong (PSM is not leaking the slot reference, or it is a different
problem entirely), then we need to determine why our tools do not demonstrate
this bug.
I talked to Ian on IRC about this bug and here is a summary
of our conversation.

We believe that the PSM code may have been leaking a reference
to the NSS internal module.

In NSS 3.3.x, the DB is not associated with the internal module,
and NSS_Shutdown closes the DB forcibly.

In NSS 3.4, the DB is associated with the internal module.  So
this leaked slot reference causes the DB to stay open.

We would like the PSM team to first investigate whether PSM
leaks a slot reference.  This can be done by setting breakpoints
in PK11_ReferenceSlot() and PK11_FreeSlot() in the debugger
and run Mozilla in the debugger to see where the leak occurs.




I think there is an open question here about the definition of NSS_Shutdown.
The question is:  
Is NSS_Shutdown a hammer that shuts things down even if there are "leaked" 
references?  Or does it politely fail when there are leaked references?  

It sounds like this definition has been (perhaps inadvertently) changed 
between 3.3.x and 3.4 from hammer to polite.  Yet, I observe that 
NSS_Shutdown returns void, and is not defined to set any error codes.
So there is no way for the caller to be aware of the failure, or to take
any corrective action.

I claim that NSS_Shutdown should be a hammer.  Leaked references or no,
it should succeed in "Destroying" all the modules.   If it is not, then
I believe it should not return void, and it should set a meaning error 
code when returning SECFailure.  
I agree with Nelson. Due to the failure to return any error code, NSS_Shutdown 
should be the hammer.

We could also add a shutdown function that is polite and returns a SECStatus and 
sets an error via PR_SetError(), but that would be an enhancement.

That actually isn't the case. NSS shutdown has always had the same semantics in
shutting down slots. If the reference was leaked, then the slot wasn't freed.
What is different is the fact that the databases were freed in shutdown, now
they are freed as part of the slot.

In one sense NSS shutdown is still a hammer, once it's called, NSS is
effectively dismantled. The slots and modules are removed from their lists. The
problem is the internal slots are still not freed, so when we go to initialize
the slots again, they still have pointers to the old cert and key databases,
rather than opening new ones.

The leaked slots should have caused some other semantic problems in NSS 3.3, so
I'm not totally convinced that it's PSM that's leaking the slot.
Could it be SSL ?
Does PSM shut down SSL and destroy all the SSL sessions before it calls 
NSS_Shutdown ?
Presumably there would be PKCS#11 sessions open with the softokn as part of the 
SSL session, and therefore slot references.

There is at least one NSS client that doesn't do SSL that experiences this.

Do CERTCertificate structs hold a slot reference, directly or indirectly?
Could a cert leak become a slot leak?
Yes, CERTCertificate's hold a slot reference, and a cert leak would correspond
to a slot leak.
Bob,

I think we need to force a call to C_Finalize for all modules at shutdown time.
 NSS previously leaked the internal slot on all SSL client connections, I
plugged this leak in 3.4.  This means that NSS shutdown cleanly in 3.3.2, even
though a slot reference was leaked.  Now that the databases are tied to slot
references, this is no longer the case.
Doing so is not exactly trivial. Slots are placed a a number of lists. At
shutdown time they are pulled off of these lists and freed. prematurely calling
finalize could interfere with this process.

In addition, we need to plug these cases so that we can delete modules from the
UI and reload them later.

That doesn't mean it can't happen, it's just that it's not as simple as it would
appear.
Blocks: 108795
Bob is working on this bug right now.

As part of fixing this bug, we should add code to
detect an attempt to call C_Initialize on the softoken
when it's already initialized, for example, if NSS_Shutdown
fails to call C_Finalize on the softoken.

If that condition is detected, the C_Initialize function
of the softoken should return the error code
CKR_CRYPTOKI_ALREADY_INITIALIZED, an assertion should
fail in debug builds, and NSS_Initialize should return
SECFailure.
Assignee: ian.mcgreer → relyea
OK, I'm about to attach to large patches.

The first is for security/nss/lib. It contains fixes for tne leaks in NSS.
The second is for security/nss/cmd. It contains fixes for leaks in the testcases.

Most leaks were in the testcases themselves, followed by pkcs12, pk11wrap, and
stan (which had just one I believe).

I'd like Ian to particularly review the fix in dev.

Leaks take on three basic types: 
1) direct leak of a slot reference. The most common case of this is calling
PK11_GetInternalSlot() or PK11_GetInternalKeySlot() without freeing the
resulting slot.
2) leaking a basic security object (key, public key, private key, or cert).
3) not freeing a composite object (or bugs in the free of a composite object)
like an S/MIMES cmsg struct or a pkcs12 context.

I've included the fixes to the cmds in the patch, since many applications have
blindly copied the cmd code (many of which leaked like a sieve). This might give
applications ideas for where their leaks are. I've also include code to
optionally assert if you call shutdown and all the modules are not freed
(controlled by setting the environment variable NSS_STRICT_SHUTDOWN). All the
NSS tests except the FIPS tests run with this environment variable set.

We tracking down the leaks on windows, I found the best way to handle it is to
set the reference count variables for each of the slots in a watch window. Then
step through the code and note where slots are referenced, but not freed. You
can usually pin point it down to a cert, key or crypto context which has
allocated the slot. Note that certs and symkeys are also reference counted
objects, so if the corresponing free is being called, but the slot reference
isn't decremented, then it's a pretty good bet that someone else has a reference
to that key or cert. You should find at start up that most slots will have one
reference (except the internal slot with will nominally have 13 (0xd)
references. If you have the environment variable set, you can look at your watch
points after the assert and see how many references you have leaked in which
slot. I found leaks in the Internal slot to be almost as common as leaks in the
key slot.
Comment on attachment 78847 [details] [diff] [review]
patch to securit/nss/lib to fix slot reference leaks which prevents shutdown

Bob,

You have two solutions for the problem that we use the
internal key slot if the caller does not specify a slot.

Solution 1: use a variable (free_slot) to remember that
we are using the internal key slot, whose reference we
need to free.  Here is an example.

>@@ -3967,6 +3965,7 @@
>     CK_OBJECT_HANDLE smimeh = CK_INVALID_HANDLE;
>     CK_ATTRIBUTE *attrs = theTemplate;
>     CK_SESSION_HANDLE rwsession;
>+    PK11SlotInfo *free_slot = NULL;
>     CK_RV crv;
> #ifdef DEBUG
>     int tsize = sizeof(theTemplate)/sizeof(theTemplate[0]);
>@@ -3987,7 +3986,7 @@
>     PORT_Assert (realSize <= tsize);
> 
>     if (slot == NULL) {
>-	slot = PK11_GetInternalKeySlot();
>+	free_slot = slot = PK11_GetInternalKeySlot();
> 	/* we need to free the key slot in the end!!! */
>     }
> 
>@@ -4004,6 +4003,10 @@
>     }
> 
>     PK11_RestoreROSession(slot,rwsession);
>+
>+    if (free_slot) {
>+	PK11_FreeSlot(free_slot);
>+    }
>     return SECSuccess;
> }
>

Solution 2: add a reference to the caller-specified
slot so that we can simply free 'slot' (which can
be either caller-specified or the internal key slot)
when we are done.  Here is an example.

>@@ -1285,7 +1292,7 @@
> 
> 	/* extract the key encrypted */
> 	SECKEYEncryptedPrivateKeyInfo *epki = NULL;
>-	PK11SlotInfo *slot = p12ctxt->slot;
>+	PK11SlotInfo *slot = NULL;
> 
> 	if(!sec_pkcs12_convert_item_to_unicode(p12ctxt->arena, &uniPwitem,
> 				 pwitem, PR_TRUE, PR_TRUE, PR_TRUE)) {
>@@ -1296,14 +1303,14 @@
> 	/* we want to make sure to take the key out of the key slot */
> 	if(PK11_IsInternal(p12ctxt->slot)) {
> 	    slot = PK11_GetInternalKeySlot();
>+	} else {
>+	    slot = PK11_ReferenceSlot(p12ctxt->slot);
> 	}
> 
> 	epki = PK11_ExportEncryptedPrivateKeyInfo(slot, algorithm, 
> 						  &uniPwitem, cert, 1, 
> 						  p12ctxt->wincx);
>-	if(PK11_IsInternal(p12ctxt->slot)) {
>-	    PK11_FreeSlot(slot);
>-	}
>+	PK11_FreeSlot(slot);
> 	
> 	keyItem = PORT_ArenaZAlloc(p12ctxt->arena, 
> 				  sizeof(SECKEYEncryptedPrivateKeyInfo));

I think we should standardize on solution 1.  Solution 2
incurs the unnecessary overhead of PK11_ReferenceSlot
and PK11_FreeSlot if the caller specifies a slot, which
the caller must already have a reference for.
Attachment #78847 - Flags: needs-work+
Comment on attachment 78847 [details] [diff] [review]
patch to securit/nss/lib to fix slot reference leaks which prevents shutdown

Bob,

You have two solutions for the problem that we use the
internal key slot if the caller does not specify a slot.

Solution 1: use a variable (free_slot) to remember that
we are using the internal key slot, whose reference we
need to free.  Here is an example.

>@@ -3967,6 +3965,7 @@
>     CK_OBJECT_HANDLE smimeh = CK_INVALID_HANDLE;
>     CK_ATTRIBUTE *attrs = theTemplate;
>     CK_SESSION_HANDLE rwsession;
>+    PK11SlotInfo *free_slot = NULL;
>     CK_RV crv;
> #ifdef DEBUG
>     int tsize = sizeof(theTemplate)/sizeof(theTemplate[0]);
>@@ -3987,7 +3986,7 @@
>     PORT_Assert (realSize <= tsize);
> 
>     if (slot == NULL) {
>-	slot = PK11_GetInternalKeySlot();
>+	free_slot = slot = PK11_GetInternalKeySlot();
> 	/* we need to free the key slot in the end!!! */
>     }
> 
>@@ -4004,6 +4003,10 @@
>     }
> 
>     PK11_RestoreROSession(slot,rwsession);
>+
>+    if (free_slot) {
>+	PK11_FreeSlot(free_slot);
>+    }
>     return SECSuccess;
> }
>

Solution 2: add a reference to the caller-specified
slot so that we can simply free 'slot' (which can
be either caller-specified or the internal key slot)
when we are done.  Here is an example.

>@@ -1285,7 +1292,7 @@
> 
> 	/* extract the key encrypted */
> 	SECKEYEncryptedPrivateKeyInfo *epki = NULL;
>-	PK11SlotInfo *slot = p12ctxt->slot;
>+	PK11SlotInfo *slot = NULL;
> 
> 	if(!sec_pkcs12_convert_item_to_unicode(p12ctxt->arena, &uniPwitem,
> 				 pwitem, PR_TRUE, PR_TRUE, PR_TRUE)) {
>@@ -1296,14 +1303,14 @@
> 	/* we want to make sure to take the key out of the key slot */
> 	if(PK11_IsInternal(p12ctxt->slot)) {
> 	    slot = PK11_GetInternalKeySlot();
>+	} else {
>+	    slot = PK11_ReferenceSlot(p12ctxt->slot);
> 	}
> 
> 	epki = PK11_ExportEncryptedPrivateKeyInfo(slot, algorithm, 
> 						  &uniPwitem, cert, 1, 
> 						  p12ctxt->wincx);
>-	if(PK11_IsInternal(p12ctxt->slot)) {
>-	    PK11_FreeSlot(slot);
>-	}
>+	PK11_FreeSlot(slot);
> 	
> 	keyItem = PORT_ArenaZAlloc(p12ctxt->arena, 
> 				  sizeof(SECKEYEncryptedPrivateKeyInfo));

I think we should standardize on solution 1.  Solution 2
incurs the unnecessary overhead of PK11_ReferenceSlot
and PK11_FreeSlot if the caller specifies a slot, which
the caller must already have a reference for.
This mirrors current usage in NSS for both referenced and malloc'ed data structures.

In general if the object is passed into us, we are presuming the caller owns a
reference/memory. If we need to 'replace' that object in our code, we use a
temporary variable to store the version we may need to 'free'.

If instead we have our own local variable, then it's clearer if we always get a
reference.

If we had to standardize on one type I would prefer the latter (though the
former would be preferable for non-reference counted objects), since it's
clearer what is going on.

bob
Bob,

I agree that the latter solution is clearer.  It's just
that it is not necessary for the callee to grab an
additional reference because the reference that's passed
in by the caller has to be good for the duration of the
call.  I am worried about the cost of the two PR_Lock
and two PR_Unlock calls in PK11_ReferenceSlot and
PK11_FreeSlot.  It is difficult to profile lock contention,
so I think it is a reasonable trade-off to sacrifice some
code clarify for lock usage reduction.

It seems that all this would be a non-issue if we had a
version of PK11_GetInternalKeySlot that did not increment
the reference count. 
Adding nsbeta1 keyword nomination for triage, this fix is needed for enabling
QuickLaunch by default, which is MachV's most important performance enhancement.
Keywords: nsbeta1
The patch looks good to me.
Keywords: nsbeta1
Keywords: nsbeta1
Comment on attachment 78847 [details] [diff] [review]
patch to securit/nss/lib to fix slot reference leaks which prevents shutdown

I reviewed this patch.	r=wtc.	I believe this patch will
apply to the NSS_3_4_BRANCH because the line numbers are
the same.

Bob, I have a question about the NSS_Shutdown function.

>Index: nss/nssinit.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/nss/nssinit.c,v
>retrieving revision 1.42
>diff -u -r1.42 nssinit.c
>--- nss/nssinit.c	15 Mar 2002 23:05:58 -0000	1.42
>+++ nss/nssinit.c	12 Apr 2002 04:26:13 -0000
>@@ -458,8 +458,8 @@
> NSS_Shutdown(void)
> {
>     SECOID_Shutdown();
>-    SECMOD_Shutdown();
>     STAN_Shutdown();
>+    SECMOD_Shutdown();
>     nss_IsInitted = PR_FALSE;
> }
> 

NSS_Shutdown always sets nss_IsInitted to false, even if
there are reference leaks.  This means the test for
nss_IsInitted in nss_Init has no effect.

Maybe NSS_Shutdown should do something like this?
    if (secmod_PrivateModuleCount == 0) {
	nss_IsInitted = PR_FALSE;
    }
Attachment #78847 - Flags: needs-work+ → review+
In pk11cert.c, PK11_SaveSMimeProfile, we also need to free
'free_slot' if we return on error.
re comment #22 NSS_Init* is idempotent. Once initialized, you can safely call
NSS_Init any time you want and have it 'succeed'. Only the first call has any
affect on the configuration (applications currently depend on this behavior).
Once shutdown has started, It is no longer possible to use NSS, even if there
are outstanding references. It's therefore important to mark that Shutdown has
occured. If we waited marking nssInited to later, then NSS will incorrectly
indicate success on the next NSS init (if we weren't shutdown cleanly).

bob
Comment on attachment 78847 [details] [diff] [review]
patch to securit/nss/lib to fix slot reference leaks which prevents shutdown

Bob, I mistook 'nsc_init' for 'nss_isIntted' in the change below.
Sorry about the confusion.

>Index: softoken/pkcs11.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/softoken/pkcs11.c,v
>retrieving revision 1.41
>diff -u -r1.41 pkcs11.c
>--- softoken/pkcs11.c	10 Apr 2002 17:56:52 -0000	1.41
>+++ softoken/pkcs11.c	12 Apr 2002 04:26:29 -0000
>@@ -2302,7 +2302,7 @@
>     int i;
> 
>     if (nsc_init) {
>-	return crv;
>+	return CKR_CRYPTOKI_ALREADY_INITIALIZED;
>     }
> 
>     rv = RNG_RNGInit();         /* initialize random number generator */
Ah, For those who don't understand the cryptic reference:

nss_IsInited is a static variable local to nssinit.c (in nss3.dll) which denotes
the state of NSS initialization (has NSS_Init*() been called). It is what is
cleared in shutdown.

nsc_initted is a static variable local in the soft token, which denotes the
state of softoken init. The softoken is a PKCS #11 module is is by definition
not idempotent. It is also the softoken part of the initialization which
controls the current databases associated with the current profile.

bob
I tried applying this patch to NSS_CLIENT_TAG, and the compile failed with the 
following error:

pk11pars.c(271) : error C2065: 'SECMOD_MODULE_DB_FUNCTION_RELEASE' : undeclared
identifier

Do I need to pull a different NSS tag if I want to test this patch?  And will 
doing that require any API changes to PSM?

Arg.

The patch contains a partial fix for a different problem. Revert the code:
@@ -262,15 +264,16 @@
 }
 
 SECStatus
-SECMOD_FreeModuleSpecList(SECMODModule *parent, char **moduleSpecList)
+SECMOD_FreeModuleSpecList(SECMODModule *module, char **moduleSpecList)
 {
-    char ** index;
-
-    for(index = moduleSpecList; *index; index++) {
-
PORT_Free(*index);
+    SECMODModuleDBFunc func = (SECMODModuleDBFunc) module->moduleDBFunc;
+    char **retString;
+    if (func) {
+
retString = (*func)(SECMOD_MODULE_DB_FUNCTION_RELEASE,
+
	module->libraryParams,moduleSpecList);
+
if (retString != NULL) return SECSuccess;
     }
-    PORT_Free(moduleSpecList);
-    return SECSuccess;
+    return SECFailure;
 }

and you should be ok.

bob
Through some evil hackery (which I may actually clean up and make a patch for),
I was able to use Mozilla's refcount balancer tool
(http://www.mozilla.org/performance/refcnt-balancer.html) to produce a refcount
leak tree for what appears to be one leaked reference to a PK11SlotInfo object.

Here's the procedure I used:
- I made the code that handles profile switching in nsNSSComponent simply exit
after calling NSS_Shutdown(), so that I would be sure to get a clean log.
- I started Mozilla with /turbo, selected a profile, visited a single SSL site
(https://www-s.uiuc.edu/), shut down the browser, and selected a second profile,
thus causing the process to exit because of the modification above.

I'm attaching both the tree (with --ignore-balanced) and the raw refcount log.

(yes, the function names aren't right for functions outside of the NSS library.
 no, I don't know why.)

Actually, the function names appear to be incorrect for anything outside the
PKCS11 module...

Ok, I did some more investigating - it turns out that the stack is bogus for a
couple of reasons: 1. only exported symbols show up, and 2. i wasn't properly
loading symbols for other libraries on the stack.

Some more looking at the problems convinced me that the remaining leak is
necko's fault.  I'm updating bug 125561 with that info.

Bob, I worked on bug 129067, and I ended up doing some leak searching in PSM
cert manager itself.

After some testing and disabling some code, I found another potential NSS
function having a leak.

I have a profile with an untrusted user cert.

As soon as I do a call to CERT_VerifyCertNow, I run into your assertion.
If I disable that call, I don't.
Blocks: 137881
Because this blocks 125561, updating keywords.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Robert - What are the chances this will be ready by Monday, 04/29?
Whiteboard: [adt2] → [adt2] [ETA Needed]
If this already has the necessary reviews, can we go ahead and check this into
NSS_3_4_BRANCH and move NSS_CLIENT_TAG? (which basically corresponds to checking
in on the trunk)

We should do this before landing on the 1.0 branch. wtc or relyea, can you take
care of this?

Bob, this section of your patch doesn't apply cleanly to NSS_3_4_BRANCH.  Do you
think you could come up with a new patch against the branch which includes
everything from attachment 78847 [details] [diff] [review], and wtc's fix (attachment 79520 [details] [diff] [review])?

Index: certdb/certdb.c
===================================================================
RCS file: /cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v
retrieving revision 1.26
diff -u -r1.26 certdb.c
--- certdb/certdb.c     9 Apr 2002 23:46:57 -0000       1.26
+++ certdb/certdb.c     12 Apr 2002 04:26:10 -0000
@@ -2051,10 +2052,10 @@
                     * otherwise if there are more than one cert, we don't
                     * know which cert it belongs to.
                     */
-                   rv = PK11_ImportCert(PK11_GetInternalKeySlot(),certs[i],
+                   rv = PK11_ImportCert(intSlot,certs[i],
                                CK_INVALID_HANDLE,NULL,PR_TRUE);
                } else {
-                   rv = PK11_ImportCert(PK11_GetInternalKeySlot(),certs[i],
+                   rv = PK11_ImportCert(intSlot,certs[i],
                                CK_INVALID_HANDLE,nickname,PR_TRUE);
                }
                if (rv == SECSuccess) {

I don't think we should check this into the 3.4 branch, as only server fixes
have been going there. The tip has been were we've been making client changes.
This patch is already checked into the tip.

The particular conflict you are seeing is one to fix other crashing problems on.
Those changes removed the initial slot leak the patch is supposed to fix, so
there is no need to apply the patch there.

So there are 3 issues, what to do about beta, want to do about 1.0 and what to
do about the mozilla trunk (client_tag).

I'm not sure enough about our processes for the beta and 1.0, so I suggest Kaie
or brian get the fixes checked into those branches.

The mozilla trunk (which I presume is represented by the CLIENT_TAG) should move
up to the NSS tip. I have no problem branching the current tip of NSS to
facilitate this.  WTC and SSAUX are working on how to make this whole thing happen.

bob

bob
This patch has the necessary changes to security/nss/lib,
including the changes to make NSS_Shutdown return SECStatus.
This patch is prepared for the MOZILLA_1_0_0_BRANCH.
This is the previous patch adapted for the NSS_3_4_BRANCH.
Bob, I think this patch is pretty safe and we should check
it into the NSS_3_4_BRANCH.  Is that OK?
Nominating ADT.
Keywords: adt1.0.0
Yes, it's safe for the NSS 3.4 branch.

bob
*** Bug 133646 has been marked as a duplicate of this bug. ***
Target Milestone: 3.4.1 → 3.5
Let's review this one in the RTM timeframe. adt1.0.0- [adt2 RTM]
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [adt2] [ETA Needed] → [adt2 RTM] [ETA Needed]
*** Bug 135053 has been marked as a duplicate of this bug. ***
*** Bug 135333 has been marked as a duplicate of this bug. ***
*** Bug 135335 has been marked as a duplicate of this bug. ***
*** Bug 135338 has been marked as a duplicate of this bug. ***
Wan-Teh landed this together with other fixes on NSS_CLIENT_TAG for the Mozilla
trunk.
Marking fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Can we get some testing of this on the trunk to ease branch approval?
Keywords: adt1.0.0- → adt1.0.0
> Can we get some testing of this on the trunk to ease branch approval?

Peter, it already landed on the trunk.

The Mozilla trunk does not use the trunk of NSS. The Mozilla trunk build scripts
use NSS snapshot that has CVS tag NSS_CLIENT_TAG.

Therefore, at the day Wan-Teh moved the tag to a newer snapshot of NSS, the
Mozilla trunk build began to use a version of NSS that is using the patches from
this bug 133584.

My understanding, however, is: The changes in this bug 133584 should not be
taken independently. What landed on the trunk were several patches to NSS, as
they are listed in bug 145836. All of them should land on the Mozilla 1.0.0 branch.

(To confuse things more: Mozilla trunk and Mozilla branches like
MOZILLA_1_0_0_BRANCH behave differently wrt NSS. Mozilla trunk uses a special
snapshot of NSS, while the branches are just using the NSS files that are
checked in to that branch.)


So to summarize: Mozilla trunk builds since 05/15/2002 have been using the new
NSS version which include the fixes from this bug.



Thanks for the clarification Kai.  It would be difficult to test and verify this
on the trunk if it hadn't landed there.
Keywords: qawanted
Keywords: adt1.0.1
Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.
Keywords: adt1.0.0
Blocks: 145836
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch. Pls check this in
asap. thanks!
Keywords: adt1.0.1 → adt1.0.1+
Whiteboard: [adt2 RTM] [ETA Needed] → [adt2 RTM] [05/31]
Keywords: adt1.0.1+ → fixed1.0.1
bishakhabanerjee@netscape.com - can you verify this bug fix in 1.01 branch? 
When verified, pls replace fixed1.0.1 keyword with verified1.0.1.  Thanks.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1
marking verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: