Room destructor does not remove FFI event listener, causing use-after-free

[Sqhh99]

Describe the bug
When a Room object is destroyed, the FFI event listener registered during Connect() is not removed. This causes subsequent callbacks to reference a destroyed object, leading to use-after-free crashes.
To Reproduce

1. Connect to a room
2. Destroy the Room object (or let it go out of scope)
3. Reconnect with a new Room
4. Crash occurs when FFI dispatches events to the old, destroyed listener

Expected behavior
The FFI listener should be removed in the Room destructor to prevent dangling callbacks.

I tried to fix this by:

1. Storing the listener ID during Connect()
2. Calling FfiClient::RemoveListener() in the destructor
3. Adding a mechanism to wait for in-flight callbacks to complete before destruction

Problem encountered

If a user destroys the Room from within a RoomDelegate callback (e.g., in onDisconnected), the destructor will deadlock because it waits for the callback to finish, but the callback is waiting for the destructor to return.
I'm unsure how to handle this edge case properly.

[xianshijing-lk]

@Sqhh99 , do you mind sharing some quick examples for those use cases?

I am going to add some integration tests and hopefully catch those corner cases.

BTW, in livekit.h, in our basic_room example, it has some cleanup code:

  // Must be cleaned up before FfiClient::instance().shutdown();
  room->setDelegate(nullptr);

  // Clean up the audio track publishment
  room->localParticipant()->unpublishTrack(audioPub->sid());

  // Clean up the video track publishment
  room->localParticipant()->unpublishTrack(videoPub->sid());

  room.reset();

  livekit::shutdown();

Have you tried similar approaches?

[xianshijing-lk]

regarding
If a user destroys the Room from within a RoomDelegate callback (e.g., in onDisconnected), the destructor will deadlock because it waits for the callback to finish, but the callback is waiting for the destructor to return.
I'm unsure how to handle this edge case properly.

I think one common pattern for such problem is to post a task to delete the room object there.
C++ has good performance and flexibility, but it also comes with some implicit rules / complexity.

[Sqhh99]

When Room::Connect() is called, it registers an FfiClient listener using FfiClient::instance().AddListener(), but the returned listenerId is only stored in a local variable and never saved to a member variable. As a result, when the
Room
object is destroyed (e.g., when a user leaves a conference), the destructor Room::~Room() has no way to call FfiClient::RemoveListener() to clean up the listener. This causes a use-after-free crash when the user attempts to rejoin a conference: the old listener still exists in FfiClient and triggers callbacks on the already-destroyed Room object. The fix should save listenerId to a member variable like listener_id_ and call FfiClient::RemoveListener(listener_id_) in the destructor.

The scenario I'm currently working on is that a user leaves the meeting, I destroy the room, create a new room, and then the user re-enters the previously joined meeting, and the program crashes. My question is, since the user simply leaves and re-enters the meeting, not actually exits the software and re-enters, is it necessary to execute code at the level of livekit::shutdown();?

After I modified the destructor in room.cpp of the SDK like this, my problem was solved.

[xianshijing-lk]

Let me come up a PR to fix it. I do think we need to remove the listener when room goes away or gets disconnected