Closed Bug 184754 Opened 22 years ago Closed 22 years ago

assertion violation in get_token_certs_for_cache

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jamie-bugzilla, Assigned: rrelyea)

Details

Attachments

(3 files, 1 obsolete file)

fix even more problems
3.70 KB, patch
Details | Diff | Splinter Review
nFast log
45.61 KB, text/plain
Details
workaround bad return value
1.15 KB, patch
Details | Diff | Splinter Review
I got the following assertion violation in a debug version of certutil, using NSS 3.7 Beta 1 with NSPR 4.2.2. I am running on Linux 2.4, and I have an nCipher device plugged in. The output is as follows: > ./certutil -d . -h nFast -L Enter Password or Pin for "nFast": Assertion failure: PR_FALSE == lock->locked, at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:174 Abort (core dumped) The assertion is that we are freeing a locked lock. Here is the stack trace: #3 0x401396ff in PR_Assert () at ../../../../mozilla/nsprpub/pr/src/io/prlog.c:516 #4 0x401518fb in PR_DestroyLock (lock=0x80926d0) at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:174 #5 0x400fe175 in nssTokenObjectCache_Destroy (cache=0x80a1588) at devutil.c:641 #6 0x400fa50b in nssToken_Destroy (tok=0x80b2988) at devtoken.c:160 #7 0x400fdc53 in nssCryptokiObject_Destroy (object=0x80b71e8) at devutil.c:90 #8 0x400fdf71 in nssCryptokiObjectArray_Destroy (objects=0x80b5420) at devutil.c:237 #9 0x400fe74f in get_token_certs_for_cache (cache=0x80a1588) at devutil.c:890 #10 0x400feed8 in nssTokenObjectCache_FindObjectsByTemplate (cache=0x80a1588, objclass=1, otemplate=0xbffebcf0, otlen=2, maximumOpt=0, statusOpt=0xbffebca4) at devutil.c:1175 #11 0x400fadd1 in find_objects_by_template (token=0x80b2988, sessionOpt=0x0, obj_template=0xbffebcf0, otsize=2, maximumOpt=0, statusOpt=0xbffebd80) at devtoken.c:522 #12 0x400fb627 in nssToken_FindCertificates (token=0x80b2988, sessionOpt=0x0, searchType=nssTokenSearchType_TokenOnly, maximumOpt=0, statusOpt=0xbffebd80) at devtoken.c:697 #13 0x400a54db in PK11_TraverseCertsInSlot (slot=0x80af120, callback=0x400a63dc <listCertsCallback>, arg=0x80b57b0) at pk11cert.c:2860 #14 0x400a6495 in PK11_ListCertsInSlot (slot=0x80af120) at pk11cert.c:3501 #15 0x0804ca53 in listCerts (handle=0x8085ea8, name=0x0, slot=0x80af120, raw=0, ascii=0, outfile=0x8065538, pwarg=0xbffebeb0) at certutil.c:606 #16 0x0804cb7d in ListCerts (handle=0x8085ea8, name=0x0, slot=0x80af120, raw=0, ascii=0, outfile=0x8065538, pwdata=0xbffebeb0) at certutil.c:643 #17 0x08050ed3 in main (argc=6, argv=0xbffebf74) at certutil.c:2480
If I specify any other argument to "-h", or if I omit the "-h", the assertion is not tripped.
Summary: assertion violation in certutil → assertion violation in get_token_certs_for_cache
Attached patch fix problems in failure paths (obsolete) — — Splinter Review
There were a number of problems in the failure paths of this code. I tested this by forcing a failure, this patch handles it correctly (the cache is cleared, and the correct results are returning by bypassing the cache). Jaime, can you test this with the nCipher device?
Upon further review, couple more fixes to be made (probably didn't affect this bug, but might as well fix them).
Attachment #109054 - Attachment is obsolete: true
Looks like Thomas ran into this as well. We should make this a candidate for the released 3.7. ------------------------------------------------------------------------ Hi Bob, NSS3.7 seems to be crashing with nCipher on Linux. I have setup a test program that will demostrates the problem. I wonder if you can take a look of it. I am not sure this is an nCipher or NSS problem yet. Steps: 1/ login familiar 2/ root password is 'netscape' 3/ su - thomask 4/ cd /u/thomask/cms/ns/cmsutils/testsrc/com/netscape/cmstools 5/ run2.sh run2 just executes certutil thanks for your help thoma
Thomas's problem is a different issue. It's not an assertion violation, it's a SEGV in a different part of the code.
Priority: -- → P1
Target Milestone: --- → 3.7
The patch helps, but does not solve my problem. Now, my test program, which generate a key pair, sign certificate and import certiifcate, works. But I changed my test program to do what CMS does. It fails. The new test program does the following: 1/ generate key pair 2/ sign CA certificate 3/ import certificate 4/ generate key pair 5/ sign OCSP certificate 6/ import certificate I got [thomask@familiar cmstools]$ ./run.sh main: jss library loaded Imported CA Assertion failure: leafCert != NULL, at PK11Finder.c:1027 And if I ran this a couple times more, I got a TokenException [thomask@familiar cmstools]$ ./run.sh main: jss library loaded CERT ERROR: org.mozilla.jss.crypto.TokenException org.mozilla.jss.crypto.TokenException at org.mozilla.jss.CryptoManager.importCertPackageNative(Native Method) at org.mozilla.jss.CryptoManager.importUserCACertPackage(CryptoManager.java:998) at com.netscape.cmscore.security.KeyCertUtil.getInternalCertificate(KeyCertUtil.jav a:618) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:603) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:579) at com.netscape.cmstools.Test.main(Test.java:109) I need to look at this a bit more
OK, reinitialize the token, the TokenException now is gone. But the assertion problem is there. #0 0x40075b11 in __kill () from /lib/i686/libc.so.6 (gdb) where #0 0x40075b11 in __kill () from /lib/i686/libc.so.6 #1 0x4003779b in raise (sig=6) at signals.c:65 #2 0x40077092 in abort () at ../sysdeps/generic/abort.c:88 #3 0x4cf0c6ff in PR_Assert () at ../../../../mozilla/nsprpub/pr/src/io/prlog.c:516 #4 0x4cdcc263 in Java_org_mozilla_jss_CryptoManager_importCertPackageNative ( env=0x8051ec4, this=0xbffea2c4, packageArray=0xbffea2c0, nickString=0xbffea2bc, noUser=0 '\000', leafIsCA=0 '\000') at PK11Finder.c:1027 #5 0x4223537a in ?? () #6 0x4222debc in ?? () #7 0x4222debc in ?? () #8 0x4222debc in ?? () #9 0x4222debc in ?? () #10 0x4222debc in ?? () #11 0x4222b195 in ?? () #12 0x403990c6 in JavaCalls::call_helper () from /share/builds/components/cms_jdk/Linux/1.4.0/jre/lib/i386/server/libjvm.so #13 0x40434065 in os::os_exception_wrapper () from /share/builds/components/cms_jdk/Linux/1.4.0/jre/lib/i386/server/libjvm.so #14 0x40399214 in JavaCalls::call () from /share/builds/components/cms_jdk/Linux/1.4.0/jre/lib/i386/server/libjvm.so #15 0x403a109d in jni_invoke () from /share/builds/components/cms_jdk/Linux/1.4.0/jre/lib/i386/server/libjvm.so #16 0x403b069d in jni_CallStaticVoidMethod () from /share/builds/components/cms_jdk/Linux/1.4.0/jre/lib/i386/server/libjvm.so #17 0x08049372 in strcpy () #18 0x40063657 in __libc_start_main (main=0x8048c60 <strcpy+200>, argc=4, ubp_av=0xbffec6c4, init=0x80488e8, fini=0x804ba0c <strcpy+11892>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffec6bc) at ../sysdeps/generic/libc-start.c:129
Anyone has any ideas?? 1012 /*************************************************** 1013 * Now lookup the leaf cert and make it into a Java object. 1014 * Apparently, the PK11 lookup checks external tokens first, 1015 * while the CERT lookup checks the database first. If the leaf is 1016 * a CA cert, we want to return the copy in the internal database 1017 * rather than the copy on the token, so we use the CERT call. We 1018 * use the PK11 call for user certs that aren't expected to be CAs 1019 * by the caller. 1020 ***************************************************/ 1021 if(slot && !leafIsCA) { 1022 PK11_FreeSlot(slot); 1023 leafCert = PK11_FindCertByIssuerAndSN(&slot, &issuerAndSN, NULL); 1024 } else { 1025 leafCert = CERT_FindCertByIssuerAndSN(certdb, &issuerAndSN); 1026 } 1027 PR_ASSERT( leafCert != NULL );
I think there is problem in PK11_FindCertByIssuerAndSN, it should not return anything. The following includes the certificate content: [thomask@familiar cmstools]$ ./run.sh main: jss library loaded Signed CA Certificate [ [ Version: V3 Subject: CN=CA1 Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: algorithm = RSA, unparsed keybits = 30 48 02 41 00 C6 FA 5C 6F 55 3A 0A 78 00 17 D0 20 42 04 AC 85 03 E1 50 56 33 3A 5B 4C BD D0 7D 12 1B 91 96 5C 8B BB 69 35 0B 78 4A BE AC BA 9E 57 B4 26 46 11 3F DF 55 6E 68 97 AB 07 93 E1 9D 65 7A A0 FD A1 02 03 01 00 01 Validity: [From: Thu Dec 12 20:44:36 PST 2002, To: Thu Dec 12 20:44:36 PST 2002] Issuer: CN=CA1 SerialNumber: [ 00] ] Algorithm: [MD5withRSA] Signature: 9F 37 CA B3 45 F8 D7 2E 33 B4 D0 57 74 5C 54 E0 B4 42 EB BA 8C C2 DD F6 CC DD 19 99 FB E7 D5 A9 8E B8 A0 02 4A 11 21 BF A3 EA 78 01 D7 2B 59 F8 51 E8 20 A0 29 8A 0A D1 42 1D 0C 65 F0 CF 20 0B ] Imported CA Certificate Signed OCSP Certificate [ [ Version: V3 Subject: CN=OCSP1 Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: algorithm = RSA, unparsed keybits = 30 48 02 41 00 B2 84 DE BB 1D E2 2F D6 BA CF 83 AA 74 34 16 DB 48 24 EC 9F C0 66 30 1C C3 18 D0 61 00 91 E4 0F 13 0C B2 98 B1 E3 D9 67 70 0F D6 C9 88 A2 2A D1 A2 A7 1F BE 21 7A 55 D8 21 C0 1F 49 90 5D 01 37 02 03 01 00 01 Validity: [From: Thu Dec 12 20:44:37 PST 2002, To: Thu Dec 12 20:44:37 PST 2002] Issuer: CN=CA1 SerialNumber: [ 01] ] Algorithm: [MD5withRSA] Signature: 16 21 3C 12 5E C4 92 F8 54 F4 7B 54 7E 93 72 FB 5E 03 74 9F 01 9B 5A AE A9 CE DC 4C 5C 61 5B 83 4B 5B E8 87 7C F5 FA E0 01 7E BF 46 D4 EB CA 63 66 FE 32 48 FE B0 7D 99 3B 85 C8 B3 E3 E2 7E 67 ] Assertion failure: leafCert != NULL, at PK11Finder.c:1027
Thomas- NSS has a mechanism for logging all activity with a PKCS#11 module. Try setting the following env variables: NSPR_LOG_MODULES=all:5 NSPR_LOG_FILE=ncipher.log NSS_DEBUG_PKCS11_MODULE=<name of nCipher module, from modutil> After running your test program, the file ncipher.log should contain everything communicated between NSS and the nCipher module. Attach it to this bug and we'll see what we can figure out. Thanks
Sorry for the delay. Not aware that I was not in the cc list. Log file attached.
Attached file nFast log —
NSPR_LOG_MODULES=all:5 export NSPR_LOG_MODULES NSPR_LOG_FILE=nfast.log export NSPR_LOG_FILE NSS_DEBUG_PKCS11_MODULE=nFast export NSS_DEBUG_PKCS11_MODULE
The first thing I notice in looking at the log is that the module is returning CKR_FUNCTION_FAILED from C_GetAttributeValue for a CKO_CERTIFICATE. I suspect it is unhappy about an unrecognized attribute type (CKA_NETSCAPE_EMAIL), but it should not be returning failure in that case. I believe that failure will result in a NULL cert, and may be the case of the crash. Bob, would you agree with this after seeing the log? What's the best thing to do, a hack to workaround it?
I guess another workaround would be to leave CKA_NETSCAPE_EMAIL off the list, then ask for it separately and ignore any failure. That would work with any token that returns the wrong rv from CK_GetAttributeValue.
Ian, do you know where that C_GetAttributes is called from? I know we have a general function which gets the attributes, and there is a work around in that function for tokens which do not implement the PKCS #11 semantics correctly for this case (NCipher is one of those tokens). bob
It's being called from here: 122 ckrv = CKAPI(epv)->C_GetAttributeValue(hSession, 123 object, obj_template, count); 124 if (ckrv != CKR_OK && 125 ckrv != CKR_ATTRIBUTE_TYPE_INVALID && 126 ckrv != CKR_ATTRIBUTE_SENSITIVE) 127 { 128 nssSession_ExitMonitor(session); 129 nss_SetError(NSS_ERROR_DEVICE_ERROR); 130 goto loser; 131 } The workaround is later on, and it expects an rv of CKR_ATTRIBUTE_TYPE_INVALID or CKR_ATTRIBUTE_SENSITIVE. The problem is that nCipher is returning CKR_FUNCTION_FAILED, which as you can see, is not handled above.
Hmm, I wonder if there's a new bug in the nCipher driver, or if there's another reason that the function is failing. It seems weird since this code is not new for NSS 3.7 (NSS 3.4 had this code a while ago). I wonder if there is something else about the function we are missing...
Well, it's not the session or object handle. Both of those appear valid just a few calls earlier. The lengths are getting set correctly as well. I wonder why we are getting 'function failed' now. Thomas, this works with NSS 3.4? bob
This is a platform specific bug. We can install CMS on Solaris with nCipher without any problem. It fails only on Linux. This could be a bug in nCipher. Let me ask nCipher people and see if they can fix the "CKR_FUNCTION_FAILED" problem in the driver. I am worrying about schedule. We need to finish CMS6.1 in mid-Jan. Last time, it took them 1-2 months to fix the last problem that was similar to this one. A workaround in NSS will be highly apprecpiated.
This is my proposed workaround, to ask for CKA_NETSCAPE_EMAIL seperately and ignore any failure. I don't know if it will fix the problem, but I'm guessing it will.
Ian, thanks for your help. Just tried the patch and I am getting the same error. But the behaviour is a bit different. Here is what I did: - reinitialize my hardware token so that it should have nothing - run my test program that will generate key, sign cert, import, generate key, sign cert, import - 1st time I ran my test, I got Assertion failure: leafCert != NULL, at PK11Finder.c:1027 - I ran the test after the 1st time, I got TokenException TokenException mean that JSS detects failuare in PK11_ImportDERCertForKey(&theDerCert, nickChars, NULL);
1st test output: [thomask@familiar cmstools]$ ./run.sh main: jss library loaded Signed CA Certificate [ [ Version: V3 Subject: CN=CA1 Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: algorithm = RSA, unparsed keybits = 30 48 02 41 00 8F 81 66 4E 6B D7 AC 33 DC EB A7 08 D4 9D C9 BC D1 B2 7F 75 BC B1 45 E1 9A 8B 26 36 F9 20 5A 4A 0A 3C 70 1E 19 82 DA 38 69 79 B7 72 4A A6 D7 70 55 05 CB DD 5A 05 80 27 1A 3C 34 E0 4F 68 BB 21 02 03 01 00 01 Validity: [From: Wed Dec 18 13:42:39 PST 2002, To: Wed Dec 18 13:42:39 PST 2002] Issuer: CN=CA1 SerialNumber: [ 00] ] Algorithm: [MD5withRSA] Signature: 34 50 00 60 9F B6 B2 2A 81 01 81 C8 D3 02 C3 DB 52 FD B2 85 76 AE C8 5F 47 83 46 D9 FA 10 E4 EE 6A 3F E4 91 51 13 CB 3D 66 C1 0B C2 3B E3 94 41 BB 64 CB 79 4C 25 8B 06 72 6F A9 C9 81 BF F6 AB ] Imported CA Certificate Signed OCSP Certificate [ [ Version: V3 Subject: CN=OCSP1 Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: algorithm = RSA, unparsed keybits = 30 48 02 41 00 D5 83 62 C6 82 D5 4A 62 FC 1A 61 1B 1F CE 16 69 F6 A8 06 99 15 60 B0 41 B3 89 8D D2 A5 A6 09 82 49 17 B1 CD B5 DC ED 3C 22 07 FA E0 C6 F2 46 E6 CA D8 39 09 36 7A 65 A9 CE 62 56 E8 18 58 86 69 02 03 01 00 01 Validity: [From: Wed Dec 18 13:42:40 PST 2002, To: Wed Dec 18 13:42:40 PST 2002] Issuer: CN=CA1 SerialNumber: [ 01] ] Algorithm: [MD5withRSA] Signature: 03 BD B9 60 92 20 97 D7 5E 0D FF D2 6F 8B B6 C4 69 17 59 FC 93 A7 22 C7 13 59 B7 9B 4F 8A 67 A1 45 43 26 BB 6B CE 10 3E 4D 1C AB 38 95 B5 B4 4F 82 45 9B 5B 91 FA 11 69 41 A6 BC 3D 55 F5 70 0B ] Assertion failure: leafCert != NULL, at PK11Finder.c:1027 ./run.sh: line 15: 19746 Aborted (core dumped) /share/builds/components/cms_jdk/Linux/CMS_6.1/bin/java -classpath ../../../../../cms/builds/classes:../../../../../cms/builds/import/jars/jaas.jar:../../../../../cms/builds/import/jars/jndi.jar:../../../../../cms/builds/import/jars/js.jar:../../../../../cms/builds/import/jars/jss3.jar:../../../../../cms/builds/import/jars/ldapjdk.jar:../../../../../cms/builds/import/jars/nis.jar:../../../../../cms/builds/import/jars/nsutil.jar:../../../../../cms/builds/import/jars/providerutil.jar:../../../../../cms/builds/import/jars/servlet.jar:/share/builds/components/cms_jdk/Linux/CMS_6.1/jre/lib/rt.jar com.netscape.cmstools.Test
2nd run output: [thomask@familiar cmstools]$ ./run.sh main: jss library loaded Signed CA Certificate [ [ Version: V3 Subject: CN=CA1 Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4 Key: algorithm = RSA, unparsed keybits = 30 48 02 41 00 E9 C9 F5 C6 C2 1A 13 BE 8B EE 76 29 DE 53 46 2B 2D 46 37 21 BF 6A C1 E6 00 F0 5F 2C 4F E7 44 F9 22 5F F0 7D EB 0D 73 2B 5E 3A A5 E2 C0 15 5C B7 01 A3 15 E8 6A CF AE 48 D8 08 62 95 7B CE D9 BD 02 03 01 00 01 Validity: [From: Wed Dec 18 13:42:46 PST 2002, To: Wed Dec 18 13:42:46 PST 2002] Issuer: CN=CA1 SerialNumber: [ 00] ] Algorithm: [MD5withRSA] Signature: 77 F2 CD 45 C4 CE 81 FE 9C EB 7A A0 33 81 F1 5E 5D E2 0C 54 37 02 9F 43 F3 F0 2F C6 48 27 BB 96 1D 1C 90 27 A2 E4 9D 4C 38 E2 06 54 A8 F1 13 F8 5B 55 1F A4 DC 00 01 50 37 FF 26 80 FC 5D 50 36 ] CERT ERROR: org.mozilla.jss.crypto.TokenException org.mozilla.jss.crypto.TokenException at org.mozilla.jss.CryptoManager.importCertPackageNative(Native Method) at org.mozilla.jss.CryptoManager.importUserCACertPackage(CryptoManager.java:998) at com.netscape.cmscore.security.KeyCertUtil.getInternalCertificate(KeyCertUtil.java:618) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:603) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:579) at com.netscape.cmstools.Test.main(Test.java:111)
Thomas, could you find out if NSS 3.6.1 (/share/builds/components/nss/NSS_3_6_1_RTM) has the same problem today? Thanks.
I just checked in a change to JSS so that it won't assert in importCertPackageNative if we fail to lookup the cert we just imported. Instead, the code throws an exception. This change will go in JSS 3.3. /cvsroot/mozilla/security/jss/org/mozilla/jss/PK11Finder.c,v <-- PK11Finder.c new revision: 1.7; previous revision: 1.6
Target Milestone: 3.7 → 3.7.1
Wan-Teh, Tried NSS3.6.1, it crashes the JVM. JVM complained that some symbols in NSS3.6.1 cannot be found. I tried NSS3.6.1 with JSS3.2, and JSS3.1.2 I want to list the versions of CMS6.1 here: - JSS3.2 - NSS3.7 - NSPR 4.2.2 I tried my test program with CMS6.01, I got a different error - JSS3.1.1 - NSS3.3.2 - NSPR 4.1.2 CERT ERROR: org.mozilla.jss.crypto.NoSuchItemOnTokenException org.mozilla.jss.crypto.NoSuchItemOnTokenException at org.mozilla.jss.CryptoManager.importCertPackageNative(Native Method) at org.mozilla.jss.CryptoManager.importCertPackage(CryptoManager.java:888) at com.netscape.cmscore.security.KeyCertUtil.getInternalCertificate(KeyCertUtil.java:626) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:603) at com.netscape.cmscore.security.KeyCertUtil.importCert(KeyCertUtil.java:579) at com.netscape.cmstools.Test.main(Test.java:147)
Question: Ian, Looks like the following version of NSS @(#)NSS 3.7 Beta Nov 27 2002 10:41:48 does not have the logging capability. I only have the following in nfast.log with NSS3.7 beta (Nov27,2002) that is currently bundled by CMS6.1 1024[82752e0]: Loaded library a.out (init) 1024[82752e0]: Loaded library /opt/nfast/toolkits/pkcs11/libcknfast.so (load lib) 1024[82752e0]: Loaded library /export/thomask/s6/alias/libnssckbi.so (load lib) But if I use my test program with the NSS3.7 that is built by myself on 12Dec2002. It will have all the PKCS11 calls. Can you confirm that we do not have the PKCS#11 logging enabled in NSS3.7 beta1? I want CMS to bundle a NSS that has the PKCS#11 logging capability. It will be very helpful.
Thomas, a version string like "@(#)NSS 3.7 Beta Nov 27 2002 10:41:48" is an optimized build. A debug build would have "(debug)" after "NSS 3.7 Beta". When you build NSS yourself, you get a debug build unless you specify BUILD_OPT=1. Ian, is your PKCS#11 logging only available in a debug build of NSS?
Yes, unless you specify -DDEBUG_MODULE in your hand builds.
On Solaris, the nCipher driver is: Module #1: enquiry reply flags none enquiry reply level Six serial number A792-36E9-BADC mode operational version 1.77.97 On Linux, the nCipher driver is: Module #1: enquiry reply flags none enquiry reply level Five serial number 566C-26D1-8768 mode operational version 1.67.15 So looks like we do have an older driver. I will check with nCipher on this also. thanks
After checking the version number, I suspect this is possible that nCipher bundles a older driver in the latest driver release. I do not want to waste your time. So let me confirm that, and will update you afterward.
Marked the bug invalid. There is strong evidence that this could be a bug in the older version of the nCipher driver.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Even though the bug may be in the nCipher driver, I would still like to check in the 2nd patch, "fix even more problems". That patch is based on doing a code review and could prevent future crashes, without changing current behavior. The last patch ("workaround bad return value") is probably not necessary, however.
Ian, it is fine to check in the second patch, "fix even more problems". I think it'll be less confusing to open a new bug for it. Please also suggest a target milestone (3.7.2 or 3.8). Thanks.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: