Closed
Bug 483963
Opened 15 years ago
Closed 15 years ago
Assertion failure in OCSP tests.
Categories
(NSS :: Libraries, defect, P1)
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.
Reporter | ||
Comment 1•15 years ago
|
||
Tests were run with: NSS_ENABLE_PKIX_VERIFY=1 PKIX_OBJECT_LEAK_TEST=1
Updated•15 years ago
|
Severity: normal → critical
Priority: -- → P1
Whiteboard: SUN_MUST_HAVE
Assignee | ||
Updated•15 years ago
|
Whiteboard: SUN_MUST_HAVE → SUN_MUST_HAVE PKIX MOZ
Assignee | ||
Comment 2•15 years ago
|
||
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)
Comment 3•15 years ago
|
||
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.
Assignee | ||
Comment 4•15 years ago
|
||
> 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 5•15 years ago
|
||
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?
Updated•15 years ago
|
Attachment #372267 -
Flags: review?(nelson) → review+
Comment 6•15 years ago
|
||
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
Assignee | ||
Comment 7•15 years ago
|
||
(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.
Description
•