Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Assertion failure in OCSP tests.

RESOLVED FIXED in 3.12.3

Status

NSS
Libraries
P1
critical
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: Slavomir Katuscak, Assigned: Alexei Volkov)

Tracking

trunk
3.12.3
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: SUN_MUST_HAVE PKIX MOZ)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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

9 years ago
Tests were run with:
NSS_ENABLE_PKIX_VERIFY=1
PKIX_OBJECT_LEAK_TEST=1
Severity: normal → critical
Priority: -- → P1
Whiteboard: SUN_MUST_HAVE
(Assignee)

Updated

8 years ago
Whiteboard: SUN_MUST_HAVE → SUN_MUST_HAVE PKIX MOZ
Blocks: 479393
(Assignee)

Comment 2

8 years ago
Created attachment 372267 [details] [diff] [review]
Patch v1 - call nss legacy chain validation call on the second consecutive validation attempt

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.
(Assignee)

Comment 4

8 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 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
(Assignee)

Comment 7

8 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
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.