Hi, After integrating JDK-6913047 [0] [1], a bug affecting Solaris SPARC was found. See JDK-8216597 [2] for further details.
This bug has been likely caused by an unaligned memory access. jdk-submit repo tests passed before integrating so it was not noticed. There are a few direct memory accesses when loading attribute values (obtained from the 1st query) to the info array buffer, pointed by nativeKeyInfoArrayRawCkAttributesPtr: (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = (ckpAttributes+i)->type; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).ulValueLen = (ckpAttributes+i)->ulValueLen; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = nativeKeyInfoArrayRawDataPtr; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = 0; (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type = CKA_NETSCAPE_DB; There is also a direct read access: *(CK_BBOOL*)(((CK_ATTRIBUTE_PTR)(((CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributes)+sensitiveAttributePosition))->pValue Whether or not these are 64-bit aligned depends on the value returned by GetByteArrayElements: if the buffer is not 8-bytes aligned (but 4), unaligned accesses would occur. This is unlikely though. Adding sizeof(unsigned long) to nativeKeyInfoArrayRawCkAttributesPtr first value should not cause issues because 1) sizeof(unsigned long) is 8 [3] and 2) CK_ATTRIBUTE alignment is 8 (larger member is a pointer). Looks to me that the problem is caused when reading the CK_BBOOL value. This is a pointer to the data side of the buffer and there are no alignment guarantees there at all: data is compacted (to save space). I cannot confirm because I'm unable to reproduce in my environment. However, and under the described hypothesis, I propose this patch: * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00/ * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00.zip Can someone try it? In case it fails again, I'd be grateful if someone can dump all the SPARC bytes of Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function so I can see exactly what the instruction at 0x2e4 offset is (for the build without this patch). @David Holmes: even though wrappedKeySizeWrappedKeyArrayPtr may have an unaligned value, looks to me that it's not directly used to access memory but used through memcpy. Thanks, Martin.- -- [0] - https://bugs.openjdk.java.net/browse/JDK-6913047 [1] - http://hg.openjdk.java.net/jdk/jdk/rev/5170dc2bcf64 [2] - https://bugs.openjdk.java.net/browse/JDK-8216597 [3] - https://docs.oracle.com/cd/E18752_01/html/817-6223/chp-typeopexpr-2.html
