[vlc-devel] [PATCH 5/7] playlist: fix deadlock on destruction while preparser adds items to playlist
filip at atch.se
Wed Mar 29 21:26:27 CEST 2017
On 2017-03-29 22:20, Rémi Denis-Courmont wrote:
> Le keskiviikkona 29. maaliskuuta 2017, 21.12.27 EEST Filip Roséen a écrit :
> > Hi Rémi,
> > On 2017-03-29 22:01, Rémi Denis-Courmont wrote:
> > > Le keskiviikkona 29. maaliskuuta 2017, 20.45.59 EEST Filip Roséen a écrit
> > > > > > It fixes the issue described in ticket [#18151], which you closed
> > > > > > as
> > > > > > a
> > > > > > duplicate of [#17652]. I would be interested to see know how
> > > > > > #18151
> > > > > > is
> > > > > > not fixed, as I did extensive testing and a lot of proof-reading to
> > > > > > inspect the relevant paths taken.
> > > > >
> > > > > I would be interested to know how a lock inversion can be fixed while
> > > > > not
> > > > > settling for one lock order or the other, nor eliminating the code
> > > > > paths
> > > > > leading to either orders.
> > > >
> > > > As stated, you are the one who closed `#18151` as a duplicate of
> > > > `#17652`; the ticket description for the former in detail describe
> > > > what lock is being taken, and why it deadlocks.
> > >
> > > It is not strictly a duplicate but more of a specific instance of it. And
> > > as ALREADY NOTED BEFORE, this is just removing one code path leading to
> > > it.
> > >
> > > I did warn Thomas that this was a playlist problem and not a preparser/
> > > prefetcher problem quite a while back. If the whole point of this patch
> > > series was to fix this bug, then it seems that you missed the point and
> > > unfortunately wasted your time.
> > I do not believe that I have wasted my time, as such it has not been a
> > waste of time (as what constitutes as "waste of time" is highly
> > subjective); you are of course entitled to your own opinion.
> > Once again, I am very interested in knowledge related to how the
> > issue described by `#18151` is reproducible after the relevant set of
> > patches.
> Given you insist on not explaining, I´m going to assume that this means that I
> am right and this is not fixing the bug.
> 18151 is a THEORETICAL bug. You fix it by giving a THEORETICAL PROOF that it
> is fixed, in other words, by enforcing a consistent lock order.
Since when it is theoretical? Please create a directory containing
some content, then open up that directory with VLC (such as specifying
it on the command line), and magically that "theoretical" issue will
turn into a practical one.
I honestly cannot see how you can even consider it to be theoretical
when it is **really** easy to reproduce by following the ticket
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel