[vlc-devel] [PATCH 2/2] win32: fix use-after-free at thread end

Rémi Denis-Courmont remi at remlab.net
Sun Sep 13 18:25:06 CEST 2020


Le tiistaina 8. syyskuuta 2020, 9.05.30 EEST Steve Lhomme a écrit :
> On 2020-09-07 16:55, Rémi Denis-Courmont wrote:
> > 	Hi,
> > 
> > Le maanantaina 7. syyskuuta 2020, 12.54.49 EEST Steve Lhomme a écrit :
> >>> Thanks for the review. I don't think the potential bug applies to
> >>> plugins: Plugin module instances must already join their threads before
> >>> they are destroyed. This should ensure that the thread code is already
> >>> back from plugin code to LibVLC's vlc_entry(). So it is safe to unload
> >>> plugins already now. If not, then I'd say that's a separate bug that
> >>> I'll look at separately.
> >>> 
> >>> I have however noticed that this patch is wrong because it mismatches
> >>> _beginthreadex() with ExitThread().
> >>> 
> >>> We have two alternatives, I think:
> >>> 1) Switch to CreateThread() like you already did on Windows Store.
> >> 
> >> The documentation for CreateThread says otherwise:
> > (...)
> > 
> > I know what it says. We have already quoted that paragraph previously, and
> > the TC already *voted* that calling LibVLC C code from a thread *not*
> > created by _beginthreadex() was safe and supported.
> 
> How am I supposed to know that ?

The discussion was partially on vlc-devel too, as I recall.

> > If you have material evidence that this decision was ill-informed, you are
> > most welcome to solicit a revision However in the mean time, this is not
> > an
> > admissible argument.
> 
> How can I know what argument I can make or not if there's no way to know
> the list of admissible argument or not ?

AFAIK, anything other than the MSDN quote which was already "determined" to be 
a skippable recommendation rather than a requirement.

If we cannot run VLC code without _beingthreadex() then:

1) DllMain() is buggy. For instance, vlc_threadvars_cleanup() calls generic C 
code *after* _endthreadex().

2) There is no point whatsoever to keep libvlc_free() exposed.

-- 
Реми Дёни-Курмон
http://www.remlab.net/





More information about the vlc-devel mailing list