Closed Bug 483963 Opened 15 years ago Closed 15 years ago

Assertion failure in OCSP tests.

Categories

(NSS :: Libraries, defect, P1)

Sun
Solaris
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.3

People

(Reporter: slavomir.katuscak+mozilla, Assigned: alvolkov.bgs)

References

Details

(Whiteboard: SUN_MUST_HAVE PKIX MOZ)

Attachments

(1 file)

chains.sh: Verifying certificate(s)  OCSPEE11.cert OCSPCA1.cert with flags  -g leaf -m ocsp -d OCSPRootDB    -t OCSPRoot
vfychain -d OCSPRootDB -pp -vv  -g leaf -m ocsp    /export/tinderlight/data/communist_32_DBG/mozilla/security/nss/tests/libpkix/certs/OCSPEE11.cert /export/tinderlight/data/communist_32_DBG/mozilla/security/nss/tests/libpkix/certs/OCSPCA1.cert  -t OCSPRoot
chains.sh: -------- Running /export/tinderlight/data/communist_32_DBG/mozilla/dist/SunOS5.11_DBG.OBJ/bin/vfychain under DBX:
/usr/dist/pkgs/sunstudio_sparc,v12.0/SUNWspro/prod/bin/dbx /export/tinderlight/data/communist_32_DBG/mozilla/dist/SunOS5.11_DBG.OBJ/bin/vfychain
chains.sh: -------- DBX commands:
dbxenv follow_fork_mode parent
dbxenv rtc_mel_at_exit verbose
dbxenv rtc_biu_at_exit verbose
check -memuse -match 16 -frames 16
run -g leaf -m ocsp -d OCSPRootDB -pp -vv /export/tinderlight/data/communist_32_DBG/mozilla/security/nss/tests/libpkix/certs/OCSPEE11.cert /export/tinderlight/data/communist_32_DBG/mozilla/security/nss/tests/libpkix/certs/OCSPCA1.cert -t OCSPRoot
Assertion failure: fnInvLocalCount == 1, at certvfypkix.c:1220
Returned value is 1, expected result is pass
chains.sh: #1238: OCSP: Verifying certificate(s)  OCSPEE11.cert OCSPCA1.cert with flags  -g leaf -m ocsp -d OCSPRootDB    -t OCSPRoot - FAILED

OCSPEE11 and OCSPCA1 are validated both via OCSP protocol, test is expected to pass.
Tests were run with:
NSS_ENABLE_PKIX_VERIFY=1
PKIX_OBJECT_LEAK_TEST=1
Severity: normal → critical
Priority: -- → P1
Whiteboard: SUN_MUST_HAVE
Whiteboard: SUN_MUST_HAVE → SUN_MUST_HAVE PKIX MOZ
This is not really a bug, but a libpkix object leak check system limitation. It stores all info in global variables, so it is impossible to have two simultaneous runs of the test in the same process. Variable fnInvLocalCount tracks this condition.

Now, in case of ocsp, when we try to validate the response, libpkix validation engine get called again. It is very normal to have such condition during normal execution, but not within object leak test. This is why we are getting the assertion.

The attached patch makes sure, that we will never call libpkix during object leak test for the second time.

Memory leak tinderbox became green with this patch and leak fixes that was recently reviewed.
Attachment #372267 - Flags: review?(nelson)
I guess I could allow a patch like this as a VERY SHORT TERM (Like, say, 
for the next week) workaround for these assertion failures.   But it's 
clearly not the right long term solution.  As you pointed out, the 
occurrence of these recursive calls to libPKIX is "very normal".  Our 
leak testing needs to cover this very normal condition.  

Please file a separate bug to address the fact that 
  libPKIX leak tests disallow recursive calls to libPKIX.
> Please file a separate bug to address the fact that 
>   libPKIX leak tests disallow recursive calls to libPKIX.
Please allow this patch in. Bug 488237 has been filed.
Comment on attachment 372267 [details] [diff] [review]
Patch v1 - call nss legacy chain validation call on the second consecutive validation attempt

Is it just my imagination?
Or is this patch also attached to bug 4877884, 
and also awaiting my review there?

Was one of those patches supposed to be a different patch?
Attachment #372267 - Flags: review?(nelson) → review+
Comment on attachment 372267 [details] [diff] [review]
Patch v1 - call nss legacy chain validation call on the second consecutive validation attempt

Given that these changes are all inside of 
  #ifdef PKIX_OBJECT_LEAK_TEST
they can't really hurt our released code.  So, r=nelson
(In reply to comment #5)
> (From update of attachment 372267 [details] [diff] [review])
> Is it just my imagination?
> Or is this patch also attached to bug 4877884,
That wrong place to attach it.

The fix integrated as a part of the patch to bug 4877884.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.