Skip to content

Conversation

@dkimitsa
Copy link
Contributor

  1. There was a classic deadlock with two locks: * thread A: CUSTOM_OBJECTS, objcBridgeLock * thread B: objcBridgeLock, CUSTOM_OBJECTS
  2. dealloc and CUSTOM_OBJECTS.remove was not atomic, as result between these two actions, after dealloc another thread might allocate new peer with same address and inserts into CUSTOM_OBJECTS. next CUSTOM_OBJECTS will drop not related Java object that will cause it to be GCed (if not retained anywhere)
  3. peers map keeps week reference to objects. as result due GC it got wiped. this lead to bug in scenario native-to-jave call that getPeerObject is not able to find Java object and it is being allocated. This is an issue for custom classes where Java object keeps state. In this case it is being lost as blank object is created.

1. There was a classic deadlock with two locks:
     * thread A: CUSTOM_OBJECTS, objcBridgeLock
     * thread B: objcBridgeLock, CUSTOM_OBJECTS
2. dealloc and CUSTOM_OBJECTS.remove was not atomic, as result
   between these two actions, after dealloc another thread might
   allocate new peer with same address and inserts into CUSTOM_OBJECTS.
   next CUSTOM_OBJECTS will drop not related Java object that will cause
   it to be GCed (if not retained anywhere)
3. peers map keeps week reference to objects. as result due GC it got wiped.
   this lead to bug in scenario native-to-jave call that `getPeerObject` is not
   able to find Java object and it is being allocated. This is an issue for
   custom classes where Java object keeps state. In this case it is being lost
   as blank object is created.
@dkimitsa
Copy link
Contributor Author

@dkimitsa dkimitsa added this to the 2.3.25 milestone Nov 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant