Steps to reproduce the problem:
Set Auto or OpenGl as video output in VLC preferences.
Play videos with VLC, close its window during video playback by clicking the button in the upper right corner.
Result: VLC process remains in the memory, I can't open VLC again until its process is killed manually. Such behavior does not occur if I stop the video before close VLC or if I close VLC using "File" menu > "Quit" instead the button in the upper right corner or if video output used is "Xvideo output (XCB)".
The reproducibility of the problem: The problem occurs randomly, it occurs with 2% of my videos.
The problem only occurs when I play video files. No file including subtitles caused the problem until now.
Indeed, this is not a VLC issue, quoting Michel Dänzer: "all relevant APIs (GLX, EGL, Vulkan WSI) explicitly allow a context to outlive the corresponding X11 window."
I'm reopening this ticket since it is affecting all VLC users on all Linux distributions.
This ticket should be closed when either libxcb/mesa fixes the issues (and is backported to stable distribs), or when we find a workaround for VLC 3.0 only.
Indeed, this is not a VLC issue, quoting Michel Dänzer: "all relevant APIs (GLX, EGL, Vulkan WSI) explicitly allow a context to outlive the corresponding X11 window."
Maybe so, but you cannot have it both ways. AS I ALREADY EXPLAINED EARLIER TODAY ON THE MAILING LIST, this bug is about a symptom of two different bugs.
One bug is present in GL drivers, notably Mesa, but it is also replicated in other proprietary drivers. Tracking them here is obviously vain and inappropriate.
That is good to know but VLC Trac is not meant for tracking wholly external bugs. We can track missing contrib backports or version updates. But Mesa is not even in contribs. And while XCB is in contribs, the contrib build is incompatible with OpenGL usage.
So we cannot fix either of them in any way. It's all up to the distributions and their respective bug trackers. And indeed, some already do have bugs filed for this.
I'm reopening this ticket since it is affecting all VLC users on all Linux distributions.
WTF? The convention is to close bugs when they are fixed in the target branch. FFS, this Trac instance is to track VLC development. There is literally nothing whatsoever to do in the VLC code base and build system if/when XCB and/or Mesa are fixed.
This ticket should be closed when either libxcb/mesa fixes the issues (and is backported to stable distribs), or when we find a workaround for VLC 3.0 only.
Of course not. There will always be some distribution with the out-of-date code, and there will always be users not installing updates. Also there are other affected GL drivers than Mesa, as well as old hardware for which Mesa can no longer be updated. Overall, the GL problem will never ever be fixed. So what? Are you going to keep this bug open forever just because it potentially affects VLC users? How is this any different from the countless notvlc bugs we have closed in the past (some of which have affected more users than this, even)?
Is there a game I'm unaware of where we should have the bigger fixed/closed ticket ratio?
This issue is still impacting many Linux users, they stop using VLC because of that.
I really think we should keep this ticket open until it is fixed or until we stop supporting VLC 3.0 (like we did for 2.x maintenance tickets when we switched to 3.0).
You are saying there is also a Qt issue, fine.
For now, I'm trying to solve the xcb/mesa issue that I can easily reproduce with Qt.
Is there a game I'm unaware of where we should have the bigger fixed/closed ticket ratio?
Trolling is not tolerated here. You have been warned.
And as the most active bug triager, every extraneous bug is an extra recurrent waste of time for me. Especially if it's assigned to a component that I am the default assignee for.
This issue is still impacting many Linux users, they stop using VLC because of that.
So what? This Trac instance is about tracking bugs in the VLC code base, not VLC PR problems. Whether you like ti or not, Mesa and XCB devs do not use it, and they don't even have user accounts.
You are saying there is also a Qt issue, fine.
For now, I'm trying to solve the xcb/mesa issue that I can easily reproduce with Qt.
And then what? The Mesa bug is a conformance problem with GL and VK specifications, but it was always there. You can reproduce the problem with VLC 1.0 already (with the XCB window provider). The user-visible regression is most likely caused by a change in Qt or the VLC Qt plugin.
Also fixing Mesa won't solve the problem for other GL drivers, notably NVIDIA's.
Is there a game I'm unaware of where we should have the bigger fixed/closed ticket ratio?
Trolling is not tolerated here. You have been warned.
And as the most active bug triager, every extraneous bug is an extra recurrent waste of time for me. Especially if it's assigned to a component that I am the default assignee for.
We all have different personal preferences about ticket management; so let's not focus on that. Thomas, I think your comment was unwarranted. Rémi, please don't issue such warnings, that's not helpful either. The exact status of the ticket is just a detail in the resolution of the issue.
This is a bug in the Qt interface that has been known for over a decade now (quote from modules/gui/qt/qt.cpp):
/* Normally, the interface terminates after the video. In the contrary, the * Qt main loop is gone, so we cannot send any event to the user interface * widgets. Ideally, we would keep the Qt main loop running until after * the video window is released. But it is far simpler to just have the Qt * thread destroy the window early, and to turn this function into a stub. * * That assumes the video output will behave sanely if it window is * destroyed asynchronously. * XCB and Xlib-XCB are fine with that. Plain Xlib wouldn't, */
GL (and possibly Vulkan) drivers, including Mesa, are in the "wouldn't be fine" camp. This only worked in versions 2.2.x and earlier because OpenGL was not the default.
One work-around consists of reverting 96fce709, but that would reopen #4606 (closed), so that's not really a good idea.
Another work-around consists of layering an extra X11 window and re-parenting it to root when the Qt main interface is closed. Then it won't be destroyed with the main interface. This will however cause visual glitches.
Something like this happens on windows, on latest branch 3.0 nightlies. Simply saying, when you open/play and close vlc, you cannot then install an update, cause install thinks that files/dlls are still bieng used. Strange. I hope you are not leaking handles on those dlls.
P.S. This was unrelated, sorry, apparently home media server app likes to capture VLC dlls and not release them! WTF.