메모리 누수 발생

[Hyungeol94]

##문제 상황
TodoItem 탭하여 MakeTodoView를 포함하는 sheet를 열고 닫는 행위를 할 때마다, 메모리 누수가 발견하는 것을 확인했습니다. 대응이 필요해 보입니다.

[Hyungeol94]

@l1004ga
MakeTodoView 내부에서 var cameraManager = CameraManager()를 새로 생성하는데, 이 부분에서 메모리 누수가 발생한 것 같습니다. 코드를 지우니 메모리 누수가 사라졌습니다! 확인해보니 cameraManager가 MakeTodoView 내부에서 사용되지 않는 것 같은데, 지워도 괜찮은 건가요?

[Hyungeol94]

다만 카메라 뷰에 진입 시에는 cameraManager를 사용하고 있어서, 메모리 누수가 여전히 발생합니다. 😢

[Hyungeol94]

아래는 GPT가 써준 평가를 참고해서 코드를 수정해보아도 괜찮을 거 같아요 :)

From the screenshot, it looks like AVFoundation (specifically AVCapturePhotoOutput) is allocating several dispatch_queue_serial objects that Instruments is labeling as “Leaked.” However, seeing these queues in Instruments does not necessarily mean you have a genuine memory leak. Here are a few reasons why these might appear and how to verify if they are truly leaks:

---

1. AVFoundation Internals

AVFoundation creates and manages its own dispatch queues internally. Each AVCapturePhotoOutput (and sometimes each capture session or other AVFoundation objects) can spawn one or more queues for handling capture, I/O, or callbacks.

• Why it appears as “Leaked” in Instruments:
  Instruments flags anything still in memory at the end of a run (or at a snapshot) as a “leaked” object if it believes that object should have been freed. However, many framework-level objects remain allocated for the lifetime of the session or even the app, and this is not always a leak.

• What to do:

  • Make sure you’re not repeatedly creating new AVCapturePhotoOutput instances without releasing or tearing down old ones.
  • If you only have one capture output and you’re not continuously reinitializing it, the queues are likely normal and will stay alive until you stop or deallocate the session.

---

2. Repeated (Re)Initialization

If your code is creating a new CameraManager or AVCapturePhotoOutput instance each time the user opens a camera screen—without tearing down the old session—then you can end up with multiple dispatch queues (one per output).

• What to check:

  • Are you reusing the same AVCapturePhotoOutput each time, or creating new outputs?
  • Are you stopping the session (session.stopRunning()) and removing the output from the session (session.removeOutput(...)) when you’re done?

• Recommended approach:

  • Reuse a single AVCapturePhotoOutput in your manager or reinitialize it only when truly needed.
  • On teardown, call session.stopRunning(), remove inputs/outputs, and let your CameraManager deinit.

---

3. Deinit & Cleanup

Even if you remove the output from the session, AVFoundation or the OS might keep some internal queues alive until certain conditions are met.

• What to do in deinit:
  • Call session.stopRunning() synchronously (avoid wrapping it in a Task at deinit time).
  • Remove all inputs/outputs from the session.
  • Make sure no external references to your CameraManager or AVCapturePhotoOutput remain.

deinit {
    if session.isRunning {
        session.stopRunning()
    }
    for input in session.inputs {
        session.removeInput(input)
    }
    for output in session.outputs {
        session.removeOutput(output)
    }
    print("CameraManager deinitialized")
}

If done correctly, the system should eventually release any queues associated with that output/session. They may not disappear instantly in Instruments, but they shouldn’t accumulate over multiple uses.

---

4. Verifying a True Leak

• Look for unbounded growth:
  If every time you open and close your camera feature, you see the number of “Leaked” queues go up (2, 4, 6, 8, …) and never drop, that suggests you’re not tearing down the old session/outputs properly.

• Check if memory usage stabilizes:
  After stopping the session, removing inputs/outputs, and letting your manager deinit, does memory usage eventually go back down or at least stop growing? If so, it’s likely not a true leak.

• Reuse vs. Recreate:
  Often, it’s more efficient and less error-prone to reuse a single AVCaptureSession or AVCapturePhotoOutput instead of recreating them repeatedly.

---

Bottom Line

Those dispatch queues are likely internal to AVFoundation. If you see them increase over time without bound, you’re probably recreating capture sessions or photo outputs without fully tearing them down. If it’s just a handful of queues that persist while your session/manager is active, that’s normal. To ensure it’s not a genuine leak:

1. Stop the session and remove outputs/inputs when you’re done.
2. Allow CameraManager to deinit.
3. Reuse the same photo output or session if possible.

If memory usage continues to climb after properly cleaning up, then it’s worth further investigation. Otherwise, a few OS_dispatch_queue_serial objects from AVCapturePhotoOutput init are generally not an actual leak.