Mixxx leaks Open and Save Panel Service processes on macOS when closed without quitting, preventing disks from being ejected

[fwcd]

Bug Description

This is kind of a strange bug. On macOS Mixxx will launch two processes named Open and Save Panel Service and QuickLookUIService whenever an open/save dialog is launched:

An easy way to reproduce this is to spawn an open dialog by selecting Choose Library in the context menu of iTunes in the library sidebar:

Now if the user quits the app using Cmd + Q or through the menu bar via Quit Mixxx, all processes exit as they should. However, if the user only closes the app using the red button:

then the Mixxx process exits while the services become orphan processes:

Now this is problematic, because these processes may hold file resources, which can prevent the user from ejecting disks (the only solution being to manually kill them). While some macOS apps stay open even when the last window is closed, it's indeed a common paradigm for single-window applications to quit entirely when the user presses the red button. In any case, these processes should exit when Mixxx exits, regardless of how it is closed.

The strange thing about this is that these processes are not child processes according to htop, they are XPC services that are managed externally somehow. Therefore I am not sure how much of a Qt bug this is compared to Mixxx, but perhaps someone else has an idea on this.

Version

2.5-alpha-26-g6b1844e469 (HEAD)

OS

macOS 13.4

[fwcd]

Possibly related:

• https://stackoverflow.com/questions/75048119/com-apple-appkit-xpc-openandsavepanelservice-does-not-terminate
• https://stackoverflow.com/questions/6987150/why-is-nsopenpanel-nssavepanel-showing-memory-leak?noredirect=1&lq=1

[Swiftb0y]

Well, If I interpret those directly, the processes themselves are probably not the problem, but the fact that they hold on to resources when they shouldn't. Maybe the issue is that we're not instructing them to release their resources?

[daschuer]

Wen you start Mixxx with mixxx --developer there should be

debug [Main] Mixxx shutdown complete with code 0

as a last console entry. Is it missing if you use the window border button? I cannot confirm it on Linux.
Maybe macOS decides to kill Mixxx instead, a timeout ...

[fwcd]

Well, If I interpret those directly, the processes themselves are probably not the problem, but the fact that they hold on to resources when they shouldn't. Maybe the issue is that we're not instructing them to release their resources?

Well, the processes shouldn't stick around, since they are definitely specific to a Mixxx instance (i.e. launching 10 instances and closing them like this will cause 20 orphan processes to linger around)

[Swiftb0y]

Mhmm, yeah that makes sense. I guess we need to instruct them to quit and then join them. I wonder why Qt doesn't take care of that though?

[Swiftb0y]

Wen you start Mixxx with mixxx --developer there should be

debug [Main] Mixxx shutdown complete with code 0

as a last console entry. Is it missing if you use the window border button? I cannot confirm it on Linux. Maybe macOS decides to kill Mixxx instead, a timeout ...

Yeah, mixxx just crashing or being killed on shutdown is also a possibility.

[fwcd]

Wen you start Mixxx with mixxx --developer there should be

debug [Main] Mixxx shutdown complete with code 0

as a last console entry.

The shutdown message is present in both cases, the logs look very similar in both cases, nothing unusual from what I can tell:

• Log for opening dialog + quitting
• Log for opening dialog + closing window

[fwcd]

Seems to be fixed as of 50d9858, so it was very likely an upstream issue that was fixed in Qt 6.

[daschuer]

How about Mixxx 2.4-alpha?

[fwcd]

Every Qt 5 build I've tried still has this issue, but there's likely not much we can do from our side given that it's likely buried somewhere deep in the Qt-AppKit-integration layer...

Since quitting the app with Cmd+Q (as opposed to just closing the window) also terminates the extra processes correctly, this shouldn't be a crucial issue.