[vlc-devel] [PATCH 5/7] playlist: fix deadlock on destruction while preparser adds items to playlist

[Rémi Denis-Courmont]

Le keskiviikkona 29. maaliskuuta 2017, 20.45.59 EEST Filip Roséen a écrit :
> > > It fixes the issue described in ticket [#18151][1], which you closed as
> > > a
> > > duplicate of [#17652][2]. 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.

> > That it can´t be reproduced with the Qt, maybe. However that it is fixed
> > sounds logically impossible.
> 
> This was extensively tested with various setups, with and without
> *Qt* (as well as with other interfaces just for good measure). This
> has little to nothing to do with the interface used as it was very
> easily reproducible "without" (`-Idummy`) any interface at all.. as
> the problem lies in how clean-up is being done (which previously
> raced, as described in `#18151`).

I stopped caring about "extensively tested" when it comes to race conditions a 
long time ago. Even more so when the bug seems still present from looking at 
the code.

How do you LOGICALLY explain the bug being fixed?

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/