Memory Leaking - High memory after Room.disconnect

[Mt-Perazim]

Summary
After leaving a LiveKit session and awaiting room.disconnect(), app memory remains high. Instruments (Leaks + Debug Memory Graph) report leaked LiveKit internals related to data channels. I perform a teardown, switched strong references to weak like mentioned in the docs, and verified my view model deinit. Still, several LiveKit objects remain and memory increases by ~30 MB on each reconnect cycle.

Environment

• LiveKit iOS SDK: 2.4.0 and 2.9.0 (updated today to check if it fixes the leaks)
• iOS / iPadOS: 18.6.2
• App stack: SwiftUI + ARKit. I publish AR frames via a custom ARVideoCapturer to a BufferCapturer → LocalVideoTrack (source: .screenShareVideo).

Memory profile

• Start/Idle (no room): ~80 MB
• In room (AR video + mic): ~800 MB
• After leaving the room: ~550 MB
• After every subsequent rejoin: +30 MB retained
  (e.g., 1st leave 550 MB → 2nd leave 580 MB → 3rd leave 610 MB, …)

Switching all LiveKit track/publication references to weak recovered ~130 MB (from ~680 MB to ~550 MB), but the main issue persists.

Leak objects reported by Debug Memory Graph

• DataChannelPair
• LiveKit.AsyncCompleter
• LiveKit.MulticastDelegate<LiveKit.DataChannelDelegate>
• LiveKit.StateSync<LiveKit.DataChannelPair.(State in _5E1FD0D2F6306987E45F26575B668A19)>
• LiveKit.StateSync<LiveKit.MulticastDelegate<LiveKit.DataChannelDelegate>.(State in _5E24999AC9573707969E43B46E111503)<> >
• LiveKit.TTLDictionary<Swift.String, Swift.UInt32>
• MutexWrapper (retained via LiveKit.AsyncCompleter and LiveKit.MulticastDelegate<…> paths)
• Foundation (retained via LiveKit.MulticastDelegate<…> paths)
• Plus many other LiveKit.StateSync<…> entries but without leaking.

Note: After my leave flow, the app-side objects do deinit (verified with logs): SessionViewModel, its Room, ARView, ARVideoCapturer, and all local tracks/publications.

Expected

• After await room.disconnect() and releasing app-side references, internal LiveKit data-channel structures should be released.
• Memory should return near the pre-join baseline.

Actual

• DataChannelPair, AsyncCompleter, MulticastDelegate<DataChannelDelegate>, StateSync<…> remain in memory; Instruments flags them as leaks.
• Memory remains elevated (~550 MB after first leave) and increases by ~30 MB per rejoin.

---

App-side code

Properties (LiveKit references kept weak per docs)

final class SessionViewModel: NSObject, ObservableObject, Identifiable {
    @Published var room = Room()

    // Tracks & publications are weak per LiveKit recommendation
    private weak var sendingVideoTrack: LocalVideoTrack?
    private weak var sendingUserVideoTrack: LocalVideoTrack?
    private weak var sendingUserAudioTrack: LocalAudioTrack?
    private weak var sendingVideoTrackPublication: LocalTrackPublication?

    // Capturer bridging ARView snapshots to BufferCapturer
    var videoCapturer: ARVideoCapturer?

    // AR
    var arView: ARView?

    // …
}

connect() (publish user audio)

func connect() async throws {
    let serverURL = ...
    let sessionAccessToken = ...

    room.add(delegate: self)
    try await room.connect(url: serverURL, token: sessionAccessToken)

    do {
        let audioTrack = LocalAudioTrack.createTrack(name: "UserAudio")
        try await room.localParticipant.publish(audioTrack: audioTrack)
        self.sendingUserAudioTrack = audioTrack
    } catch {
        throw SessionError.noAudioDeviceAvailable
    }
}

startSendARVideo() (create buffer track, start custom capturer, publish)

@MainActor
func startSendARVideo() async throws {
    let captureOptions = BufferCaptureOptions(dimensions: .h720_169, fps: 30)
    let videoTrack = LocalVideoTrack.createBufferTrack(
        name: "ARVideo",
        source: .screenShareVideo,
        options: captureOptions
    )
    self.sendingVideoTrack = videoTrack

    guard let bufferedCapturer = videoTrack.capturer as? BufferCapturer else {
        throw SessionError.noBufferCapturerAvailable
    }

    let capturer = ARVideoCapturer(bufferedCapturer: bufferedCapturer)
    capturer.isCoachingActiveProvider = { [weak self] in self?.isCoachingActive ?? false }
    capturer.startCapture(of: arView)
    self.videoCapturer = capturer

    let screenShareEncoding = VideoEncoding(maxBitrate: 3_000_000, maxFps: 30)
    let publishOptions = VideoPublishOptions(
        name: "ARVideo",
        encoding: nil,
        screenShareEncoding: screenShareEncoding,
        simulcast: false,
        simulcastLayers: [],
        screenShareSimulcastLayers: [],
        preferredCodec: nil,
        preferredBackupCodec: nil,
        degradationPreference: .maintainFramerate,
        streamName: nil
    )

    let pub = try await room.localParticipant.publish(videoTrack: videoTrack, options: publishOptions)
    self.sendingVideoTrackPublication = pub
}

stopSendARVideo() (unpublish + explicit stop)

@MainActor
func stopSendARVideo() async throws {
    if let sendingVideoTrackPublication {
        try await room.localParticipant.unpublish(publication: sendingVideoTrackPublication)
    }

    videoCapturer?.stopCapture()
    sendingVideoTrackPublication = nil

    if let videoTrack = sendingVideoTrack {
        try await videoTrack.stop()
        sendingVideoTrack = nil
    }
}

disconnect() (teardown, then replace room)

@MainActor
func disconnect() async throws {
    // Unpublish & stop capture
    try await stopSendARVideo()

    // Clean up LiveKit
    await room.localParticipant.unpublishAll()
    room.remove(delegate: self)
    await room.disconnect()

    // Pause AR
    if let arView { arView.session.pause() }

    // Clean up tracks
    sendingVideoTrackPublication = nil
    try await sendingVideoTrack?.stop()
    sendingVideoTrack = nil
    try await sendingUserVideoTrack?.stop()
    sendingUserVideoTrack = nil
    try await sendingUserAudioTrack?.stop()
    sendingUserAudioTrack = nil

    // Clean up capturer + ARView
    videoCapturer?.stopCapture()
    videoCapturer = nil
    arView = nil
}

Questions

Am I missing something that still needs to be released?

[pblazej]

@Mt-Perazim thank you for your report!

The current behavior is that data channels are just stored properties inside Room, not leaks per se - it did not change in recent versions at all:

lazy var subscriberDataChannel = DataChannelPair(delegate: self)
lazy var publisherDataChannel = DataChannelPair(delegate: self)

Does destroying the Room help?
Is it reproducible with our example apps? (my own recording below)

Can you attach a minimal reproducible example (project)? Or your Instruments recording?

I believe the leak may be coming from the capturer itself (webrtc) rather than the Swift side.

[pblazej]

FYI @Mt-Perazim may be related to #420

[Mt-Perazim]

@pblazej
Thanks for your quick respond!

I re-checked on the example project and realized a small but important difference. The example project uses only one room over the app lifetime. So rejoining on the same or different rooms, just reuses the room object but it does not dispose it (in the case of leaving).

In my application I had a room object for each session, so in every SessionViewModel I created a new room and if leaving it, I disposed it and I thought thats the way to go. But now it makes all sense. You do not get the leak in the example project, because the only case you dispose the room is when you kill the application or it gets disposed by the OS.

So I changed my way of using the room object by doing it the same way as in the example project and got rid of almost all the leaks. I had 44 leaks, but now there is only one :)

[pblazej]

@Mt-Perazim let's try to extract the root cause, you should be able to kill the Room and return to a semi-clean state (minus lazily initialized objects in both Swift and Obj-C++).

However, the diagnosis in the description does not seem correct to me, also you mentioned some non-trivial parts like:

custom ARVideoCapturer to a BufferCapturer

That can easily leak from the libwebrtc area.

Also, you did not mention which objects contribute to this 30MB+ (based on sorted Allocations).

We'll retest Room reuse scenarios on our end, but I cannot promise anything for your particular problem without a more complete example (including the media capturing code).

[pblazej]

@Mt-Perazim I retested iOS example using this branch livekit-examples/swift-example#82

The memory "drift" between reconnects is 1-2MB, related to audio transceivers not being stopped/reused (this is not completely solved #420)

Again, my hypothesis is that we should focus on the custom code around BufferCapturer or DataChannelPair that you mentioned for your example - can't tell more without the actual code.