Interface/vout window race condition on MacOSX
The shared state between MacOSX Interface and vout window (macosx.m) is not correctly handled and lead to crash. I've attached two screenshots here: the first shows a dialog window that get shown at the startup of the interface and delay its setup, and the second shows the crash happening.
As far as I understand this issue, the main point here is that MacOSX external window should check the shared state between the interface and avoid crashing by failing instead. I don't know whether it would lead to the second issue, being that MacOSX interface would not be loaded at all and MacOSX vout window would fail.
According to the stacktrace though, I have the feeling that the macosx interface is enough started to signal that it will be existing. I cannot reproduce to test though since I cannot reproduce after confirming the bug, but we should be able to setup the necessary tests in the following function.
5 libmacosx_plugin.dylib 0x000000011828cdd6 -[VLCVideoOutputProvider setupVoutForWindow:withProposedVideoViewPosition:] + 4230
The stacktrace:
╰─$ ./bin/vlc-osx-static ~/Desktop/foo 130 ↵
VLC media player 4.0.0-dev Otto Chriek (revision 4.0.0-dev-13146-gfb11841382)
[00007ffee0c05010] main generic error: cannot load plug-in /Users/unidan/Workspace/vlc/build-macosx/modules/.libs/libebur128_plugin.dylib: dlopen(/Users/unidan/Workspace/vlc/build-macosx/modules/.libs/libebur128_plugin.dylib, 1): Library not loaded: libebur128.1.dylib
Referenced from: /Users/unidan/Workspace/vlc/build-macosx/modules/.libs/libebur128_plugin.dylib
Reason: image not found
[00007ffdb840e3d0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[00007ffdb8840c00] videotoolbox decoder: Using Video Toolbox to decode 'h264'
2020-09-20 18:53:52.746 vlc-osx-static[32071:4353467] Can't find app with identifier com.apple.iTunes
2020-09-20 18:53:52.794 vlc-osx-static[32071:4353467] Can't find app with identifier com.spotify.client
2020-09-20 18:53:52.795 vlc-osx-static[32071:4353467] Can't find app with identifier com.apple.iTunes
2020-09-20 18:53:52.834 vlc-osx-static[32071:4353467] Can't find app with identifier com.spotify.client
2020-09-20 18:53:52.837 vlc-osx-static[32071:4353467] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSDictionaryM setObject:forKey:]: object cannot be nil (key: {length = 8, bytes = 0x306d47b8fd7f0000})'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff39838b57 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff7267f5bf objc_exception_throw + 48
2 CoreFoundation 0x00007fff398e759e -[__NSCFString characterAtIndex:].cold.1 + 0
3 CoreFoundation 0x00007fff398f210c -[__NSDictionaryM setObject:forKey:].cold.3 + 0
4 CoreFoundation 0x00007fff39776299 -[__NSDictionaryM setObject:forKey:] + 976
5 libmacosx_plugin.dylib 0x000000011828cdd6 -[VLCVideoOutputProvider setupVoutForWindow:withProposedVideoViewPosition:] + 4230
6 libmacosx_plugin.dylib 0x000000011828edd7 __WindowEnable_block_invoke + 87
7 libdispatch.dylib 0x00007fff737ce658 _dispatch_client_callout + 8
8 libdispatch.dylib 0x00007fff737da7ab _dispatch_async_and_wait_invoke + 87
9 libdispatch.dylib 0x00007fff737ce658 _dispatch_client_callout + 8
10 libdispatch.dylib 0x00007fff737d9cab _dispatch_main_queue_callback_4CF + 936
11 CoreFoundation 0x00007fff397fbe81 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
12 CoreFoundation 0x00007fff397bbc87 __CFRunLoopRun + 2028
13 CoreFoundation 0x00007fff397bae3e CFRunLoopRunSpecific + 462
14 HIToolbox 0x00007fff383e7abd RunCurrentEventLoopInMode + 292
15 HIToolbox 0x00007fff383e77d5 ReceiveNextEventCommon + 584
16 HIToolbox 0x00007fff383e7579 _BlockUntilNextEventMatchingListInModeWithFilter + 64
17 AppKit 0x00007fff36a2d039 _DPSNextEvent + 883
18 AppKit 0x00007fff36a2b880 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
19 AppKit 0x00007fff36d2def2 -[NSApplication _doModalLoop:peek:] + 315
20 AppKit 0x00007fff36d2cc85 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 64
21 AppKit 0x00007fff36d2cc32 __35-[NSApplication runModalForWindow:]_block_invoke + 70
22 AppKit 0x00007fff36d2c4c4 _NSTryRunModal + 100
23 AppKit 0x00007fff36d2c3a9 -[NSApplication runModalForWindow:] + 128
24 AppKit 0x00007fff36eb57bc __19-[NSAlert runModal]_block_invoke_2 + 147
25 AppKit 0x00007fff36eb5716 __19-[NSAlert runModal]_block_invoke + 70
26 AppKit 0x00007fff36d2c4c4 _NSTryRunModal + 100
27 AppKit 0x00007fff36dc6d87 -[NSAlert runModal] + 121
28 AppKit 0x00007fff36a33bfe __55-[NSPersistentUIRestorer promptToIgnorePersistentState]_block_invoke + 908
29 AppKit 0x00007fff36a33833 -[NSApplication _suppressFinishLaunchingFromEventHandlersWhilePerformingBlock:] + 25
30 AppKit 0x00007fff36a337e3 -[NSPersistentUIRestorer promptToIgnorePersistentState] + 229
31 AppKit 0x00007fff36a334a4 -[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:completionHandler:] + 171
32 AppKit 0x00007fff36a332e6 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 536
33 AppKit 0x00007fff36a32f38 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 688
34 Foundation 0x00007fff3be2aa26 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 308
35 Foundation 0x00007fff3be2a890 _NSAppleEventManagerGenericHandler + 98
36 AE 0x00007fff3ab2f203 _AppleEventsCheckInAppWithBlock + 18103
37 AE 0x00007fff3ab2e929 _AppleEventsCheckInAppWithBlock + 15837
38 AE 0x00007fff3ab26bd7 aeProcessAppleEvent + 449
39 HIToolbox 0x00007fff383f97fa AEProcessAppleEvent + 54
40 AppKit 0x00007fff36a2d2d1 _DPSNextEvent + 1547
41 AppKit 0x00007fff36a2b880 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
42 AppKit 0x00007fff36a1d58e -[NSApplication run] + 658
43 vlc-osx-static 0x000000010effd66d main + 1709
44 libdyld.dylib 0x00007fff73827cc9 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
[1] 32071 abort ./bin/vlc-osx-static ~/Desktop/foo --play-and-exit
Activity
Added attachment:
Added attachment:
Hi!
This is the default after having compiled, in embedded mode, so if I'm not wrong: decoration on, fullscreen off, no additional vout properties.
But it doesn't really matter here, it crashes at the enable() callback for the macosx embedded vout window provider. What I forgot to add is that if I first start the interface alone, there is no crash, and in particular I'm able to answer the dialog window. Then if I start the video, it works. After having answered the dialog window which accordingly seems to prevent the «reload» of the last window state, there is no more crash.
What happens here is usual on every platform (we had the same on Qt): interface and vout window are starting asynchronously, so there's no guarantee in VLC that one will be ready before the other, and in this situation the OS exacerbate this absence of guarantee by pausing the interface window start (meaning, the event loop probably waits before the window itself is started to handle the dialog events and other dispatched events) while VLC continue to initialize the vout thread, including vout window.
interface and vout window are starting asynchronously
I fear this is might not be the reason here. On macOS, both the interface is started on the main thread, and it should be initialized well enough, before we call libvlc_playlist_play on the same thread.
This issue here seems different and related to how those OS triggered popups are handled.
Hi,
interface and vout window are starting asynchronously I fear this is might not be the reason here. On macOS, both the interface is started on the main thread, and it should be initialized well enough, before we call libvlc_playlist_play on the same thread.
AFAIK, the fact that interface and vout window are starting asynchronously is «true», so I'm not sure what you rely on for your assumption.
Also, even on MacOSX, the MacOSX interface is started by libvlc_playlist_play too, and not the reverse (you can check darwinvlc.m for that). Then libvlc parse the command line arguments, including potential media to start. Then the macosx interface will start, but because of what I mentioned above, would be stalled until we click on «yes, start the application even if it crashed before». I guess it's stalled in between willfinishlaunching/didfinishlaunching or such other events, before it setups the needed state. In the mean time, libvlc has started the playback for one item (because Open() for the interface in VLCMain.m returned) so the main playlist is running and starting an item.
Thus, I agree that the Open() of the macosx interface has bene called (otherwise, it would not be a macosx-only issue and it would not be fixable without going through the core) but I'm not sure what would block the initialization of the incriminating input_thread_t and I'm pretty sure by the stacktrace above that UI is stuck somewhere while still running an eventloop for the main thread on top of the UI.
In my opinion, the correct solution would be to add a mutex+bool in a synchronized UI state, initialized to a
falsevalue, and put it to true when the interface is really ready to call[VLCVideoOutputProvider setupVoutForWindow:], and otherwise wait in the vout thread (because we know it would start but we also know it's currently stuck) before submitting the request. Of course, I mentioned synchronized but it's a different issue (where vout could be started though the UI doesn't exist at all, eg. libvlc).Another solution could be to have a dedicated queue for the vout window and display, that the UI view will configure to offload into the dispatcher main queue when it's ready. With blocking dispatch for the window, it would achieve the same effect.
Also, even on MacOSX, the MacOSX interface is started by libvlc_playlist_play too
The mac interface is initialized by libvlc_add_intf in darwinvlc.m, not by libvlc_playlist_play, IIRC. The time libvlc_playlist_play is called the interface should be ready enough. Thats the only point I tried to make.
In any case, the issue is that
[[VLCMain sharedInstance] mainWindow]returns NULL, which should not happen here, because that is already initialized in the open callback of the interface itself (which already has been called before by libvlc_add_intf).
Serialization between vout thread and UI thread already happens by dispatching the call to setupVoutForWindow: to the main thread, which should be enough. So I do not think the idea of adding some kind of mutex there is really the correct solution here.
Can we somehow reproduce the issue / trigger the dialog window?
The mac interface is initialized by libvlc_add_intf in darwinvlc.m, not by libvlc_playlist_play, IIRC. The time libvlc_playlist_play is called the interface should be ready enough. Thats the only point I tried to make.
Ah yes indeed, sorry for misinterpretating the code.
Serialization between vout thread and UI thread already happens by dispatching the call to setupVoutForWindow: to the main thread, which should be enough. So I do not think the idea of adding some kind of mutex there is really the correct solution here.
The point is that the main queue is running in an inner loop and not the loop in darwinvlc.m, so as to handle the dialog events. So it would still be executed although the interface could be in an incorrect state. I'm not sure it's fixable in the Open() without just blocking the whole VLC startup with the dialog, which could make sense. Otherwise yes, I prefer the queue-based solution.
Can we somehow reproduce the issue / trigger the dialog window?
Nothing more easy, make VLC crash enough (add assertions for example) until you get the dialog. Always launch VLC with an input media parameter.
mentioned in issue #25436 (closed)
changed milestone to %4.0
added Component::Video: macOS / iOS / tvOS / visionOS label
added Severity::blocker label
mentioned in issue #23571 (closed)
assigned to @alexandre-janniaux
mentioned in issue #28701
