[vlc-devel] commit: Implement access_GetParentInput and demux_GetParentInput and use. ( Pierre d'Herbemont )

[xxcv]

Hi,
> With the subtitles from the video here is what I get:
> Assertion failed: (internals->i_children == 0), function 
> __vlc_object_release, file ../../src/misc/objects.c, line 627. (in 
> input destruction)
That is what I got with no interface.
With qt4 interface it assert() right here src/misc/objects.c

    /* Any thread must have been cleaned up at this point. */
    assert( !p_priv->b_thread );

>
> After reverting the two commits about access_GetParentInput and 
> demux_GetParentInput, and rebuilding from make clean, the problem is 
> still here so this seems not related after all.
That's weird after 2 reverts here then make clean remaked it then all is 
fine again.. So we're not getting the same results as I would have 
expected but since you're running on Mac and I'm on Windows.
>
> Some investigation shows that "access", "demux", "aout", "vout" that 
> are still attached to the input. There seems to be some kind of race 
> conditions as it doesn't reproduce at 100%.
Hmm... Here it always happens.
Process Explorer: one of the threads that triggered the assert() vai the 
quit signal from qt4 intf;
--
ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7
ntoskrnl.exe!memset+0x22a
ntoskrnl.exe!KeWaitForSingleObject+0x2cb
ntoskrnl.exe!KeDetachProcess+0x120d
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3
ntoskrnl.exe!memset+0x4df
ntoskrnl.exe!KeWaitForSingleObject+0x2cb
win32k.sys!memset+0xddf
win32k.sys!memset+0xe76
win32k.sys!memcpy+0x11626
ntoskrnl.exe!ZwUnloadKeyEx+0x20d3
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6a9
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x665
USER32.dll!WaitMessage+0x15
USER32.dll!GetCursorFrameInfo+0x7c
USER32.dll!SetMessageQueue+0x348
USER32.dll!SetMessageQueue+0x4ef
USER32.dll!MessageBoxTimeoutW+0x52
USER32.dll!MessageBoxTimeoutA+0x76
USER32.dll!MessageBoxExA+0x1b
USER32.dll!MessageBoxA+0x18
msvcrt.dll!strerror_s+0x9cf
msvcrt.dll!_assert+0x63d
libvlccore.dll!__vlc_object_release+0x5cd
libvlccore.dll!input_MetaTypeToLocalizedString+0x6dc
libvlccore.dll!input_Stop+0x426
libvlccore.dll!input_Stop+0x7ace
libvlccore.dll!vlc_thread_create+0x161
libvlccore.dll!vlc_threadvar_set+0x79
msvcrt.dll!wcstombs+0x3a
msvcrt.dll!_beginthreadex+0xc9
kernel32.dll!BaseThreadInitThunk+0xe
ntdll.dll!RtlCreateUserProcess+0x8c
ntdll.dll!RtlCreateProcessParameters+0x4e
--
I suppose that the core isn't counting the number of objects that are 
running or not running properly or there's a memory leak some where.
>
> First, demux and access don't properly implement refcounting. If 
> someone is holding a reference to it, its data might get destroyed, 
> and lead to crash for free. (They should implement a destructor or set 
> at list its destroyed instance variable to NULL).
The problem I see it here is that access file (the .srt file) gets 
removed and boom! it triggers the assert or even earlier if user choose, 
disable subtitle track first, it wouldn't trigger the assert then it'll 
crash the hard way.

>
> Then, aout and vout are not properly detached. That means that if 
> someone hold a vout, an input might end up in having a vout still 
> attached.
Indeed.
Why does this only get triggered after these 2 commits ?!

Regards,