Bugzilla

The stack trace shows a crash in `nssCKFWObject_GetAttribute` while accessing `fwObject->mutex`. This suggests that `nssCKFWObject_Destroy` was called on `fwObject` while the crashing thread was in `nssCKFWObject_GetAttribute`.

A review of `nssCKFWObject_Destroy` call sites shows the following in `NSSCKFWC_FindObjects`.
```
        phObject[i] = nssCKFWInstance_FindObjectHandle(fwInstance, fwObject);
        if ((CK_OBJECT_HANDLE)0 == phObject[i]) {
            phObject[i] = nssCKFWInstance_CreateObjectHandle(fwInstance, fwObject, &error);
        }
        if ((CK_OBJECT_HANDLE)0 == phObject[i]) {
            /* This isn't right either, is it? */
            nssCKFWObject_Destroy(fwObject);
            goto loser;
        }
```
upshot: the comment's author was correct.

The call to `nssCKFWInstance_FindObjectHandle` returns null if `fwObject` does not yet have a handle.

The call to `nssCKFWInstance_CreateObjectHandle` typically creates a handle for `fwObject`, but it returns null and sets `error = CKR_GENERAL_ERROR` if fwObject does have a handle.

Both functions are thread safe, but in a multithreaded environment the caller must view a null return from `nssCKFWInstance_CreateObjectHandle` as a potential success: Another thread may have created a handle for fwObject after the call to `nssCKFWInstance_FindObjectHandle`.

I believe this explains the crash in `nssCKFWObject_GetAttribute`, since `nssCKFWObject_GetAttribute` is frequently called after `NSSCKFWC_FindObjects`.

I'm also adding the signature `[@ je_free | nssCKFWObject_Destroy | NSSCKFWC_FindObjects | builtinsC_FindObjects ]`. This would happen if three threads got simultaneous null returns from `nssCKFWInstance_FindObjectHandle`. One would set the handle, another would destroy the object, and the third would crash in destroy.

The stack trace shows a crash in `nssCKFWObject_GetAttribute` while accessing `fwObject->mutex`. This suggests that `nssCKFWObject_Destroy` was called on `fwObject` while the crashing thread was in `nssCKFWObject_GetAttribute`.

A review of `nssCKFWObject_Destroy` call sites shows the following in `NSSCKFWC_FindObjects`.
```
        phObject[i] = nssCKFWInstance_FindObjectHandle(fwInstance, fwObject);
        if ((CK_OBJECT_HANDLE)0 == phObject[i]) {
            phObject[i] = nssCKFWInstance_CreateObjectHandle(fwInstance, fwObject, &error);
        }
        if ((CK_OBJECT_HANDLE)0 == phObject[i]) {
            /* This isn't right either, is it? */
            nssCKFWObject_Destroy(fwObject);
            goto loser;
        }
```
upshot: the comment's author was correct.

The call to `nssCKFWInstance_FindObjectHandle` returns null if `fwObject` does not yet have a handle.

The call to `nssCKFWInstance_CreateObjectHandle` typically creates a handle for `fwObject`, but it returns null and sets `error = CKR_GENERAL_ERROR` if fwObject already has a handle.

Both functions are thread safe, but in a multithreaded environment the caller must view a null return from `nssCKFWInstance_CreateObjectHandle` as a potential success: Another thread may have created a handle for fwObject after the call to `nssCKFWInstance_FindObjectHandle`.

I believe this explains the crash in `nssCKFWObject_GetAttribute`, since `nssCKFWObject_GetAttribute` is frequently called after `NSSCKFWC_FindObjects`.

I'm also adding the signature `[@ je_free | nssCKFWObject_Destroy | NSSCKFWC_FindObjects | builtinsC_FindObjects ]`. This would happen if three threads got simultaneous null returns from `nssCKFWInstance_FindObjectHandle`. One would set the handle, another would destroy the object, and the third would crash in destroy.