vlc-3.0.17-win32-0b23c96a leaks 4 handles after playing a local video file

assigned to @robUx4

added Component::Video: Direct3D / Win32 label

mentioned in merge request !1177 (merged)

Do you have the Windows SDK installed by any chance ?

yes i have it ... do you need i do some debug?

if you mean that leaks are related to Windows SDK i don't think so because the leaks occurs on every windows computer i tried (without Windows SDK installed). You can reproduce the leak easily. 3.0.16 has no problems instead.

the leak only occurs with video files, do not happen with audio files

and

the leak occurs also with video and audio disabled so i guess it's something in the core or in the input modules.

How do you disable the video?

What happens if you change the video output module? What happens if you disable hw decoding?

i have changed to dummy video:

i have changed to dummy audio:

i have disabled hardware decoding:

and still there are 4 handles leak after every local video file play

To help you narrow down the source of the problem i attach 2 memory dumps of vlc-3.0.17-win32-0b72ae60.zip (11 January 2022)

the first dump is vlc714_7.dmp it has 714 handles and 7 thread and i just played the video file a couple of times

the second dump is vlc1976_6.dmp it has 1976 handle and 6 htreads and it's about 30 minutes after playing a video file in a loop

dump file is too big to attach so i stored on my web site here

hope you can find the source of the leak

again note that there is no handles leak with vlc 3.0.16 so for sure it's one of the last changes in 3.0.17

The culprit is probably 5af494a1

Even with video disabled?

I analyzed all the night builds of the last few months and found that the problem started with the build of 11 July 2021

The previous day's build did not leak any handles.

Now it would be interesting to know what changes there are between the 2 builds that may have created this problem in vlc win32

The only changes on matching date and branch are the FFmpeg 4.4 upgrade.

if so it's a bad news ... it's outside the vlc developement ... i will make more test and find wich module cause the problem to narrow down the area

You can take the plugins/codec/libavcodec_plugin.dll from the 2021-07-10, put it in the 2021-07-11 build and it should be working as expected. If so that will confirm the issue is with the FFmpeg upgrade.

My point was that the changeset that introduced FFmpeg 4.4 in contribs was the only matching change. That does not necessarily imply that the leak is in FFmpeg as opposed to the VLC code that was changed simultaneously.

There were also some headerd removed but I doubt that's the issue. The issue may be in our code using libavcodec/libavformat and not the contrib code itself.

ok i will do it and i will report the results

I confirm that replacing plugins / codec / libavcodec_plugin.dll with that of 2021-07-10 the problem is solved. I also did the same operation with today's night build and also in this case the leak on the handles is gone. So the 4 handle leaks come from plugins / codec / libavcodec_plugin.dll of 11 July 2021 or later.

I confirm this seems related to ffmpeg. If I run with the same configuration (dummy aout/vout, no hw-decoder) with an extra "--codec=faad,none" there's no handle leak anymore. There are leaks with libavcodec is used to decode the video.

There's also no leak when using "--codec=faad,mft" which uses Media Foundation to decode the video.

I tried ffmpeg 4.4 without this patch for the threading API used. But it still leaks the same.

sorry for the offtopic: I didn't know it was possible to use MediaFoundation codecs. Is it also possible using it with libvlc? i tried passing "--codec=faad,mft" to libvlc_new but i only get a black screen

mft was mostly broken for H264 until recently. I'm not sure it even works in current 3.0.

Anyway, it seems to work with libavcodec/ffmpeg when using --avcodec-threads=1.

It turns out that even without the patch it's still picking the old pthreadGC2 implementation from 3.0. And it turns out that's the culprit.

When calling some threading API's from threads that were not created by pthreadGC2 (ie VLC threads) it's creating a fake internal thread object. And the object is never released. It happens twice during each playback.

These events are supposed to be released when pthread_win32_thread_detach_np() and pthread_win32_process_detach_np() are called. It is called during DLL_THREAD_DETACH and DLL_PROCESS_DETACH if pthreadGC2 is compiled in DLL mode. But it's not in our case.

There is a mechanism in static lib that calls these when the process exits. But this is useless in this case.

There are a few possible solutions to fix this:

switch to winpthread from Mingw64 but we need to ensure it works in Windows XP.
build pthreadGC2 as a DLL and ship it next to libvlccore.dll.
hack pthreadGC2 to not create a cancelEvent when called outside of a pthreadGC2 thread, but that means cancelation is not possible on those threads.
disabling all the cancelation API's in pthreadGC2 and see if all the 11 contribs that depend on it build fine. But internally even sem_wait() uses it so we would need to disable it as well.

changed milestone to %3.0.17

mentioned in merge request !1376 (merged)

i just tested the last nightly build of 3.0.17 Win32 and the problem is fixed.

https://artifacts.videolan.org/vlc-3.0/nightly-win32/20220213-0217/

Thank you

closed

added Status::fixed label

vlc-3.0.17-win32-0b23c96a leaks 4 handles after playing a local video file

Child items ...

Activity