[vlc-devel] commit: Qt4: store input_item_t* in plitem and handle metadata in model ( Ilkka Ollakka )

Jakob Leben jakob.leben at gmail.com
Fri Aug 14 14:54:22 CEST 2009

I think you both didn't realize the subtle problem that I tried to convey.

Assumption 1: when a thread receives "item added" callback, it doesn't react
immediately but only when returning to qt event loop (that's how things work
right now), so it doesn't immediately rise refcount on the new item.
Assumption 2: it is possible to playlist_remove a parent and it's child
without the parent's pointer to the child being adjusted, because "we don't
need the parent anymore" (I am not sure about that)

Under those assumptions the problem is:

1. We enter a function: int get_teeth_count_of_a_child ( QModelIndex
child_index );

2. We try to get the lock on playlist, but another thread has the lock
already. We wait for that thread.

3. The other thread creates a child item, raise it's refcount to 1, adds it
to a parent who's pointer is in the *child_index*, then unrefs both: we had
a refcount on the parent but we didn't get opportunity to raise refcount on
the child -> the child gets freed, but the parent not, but the parent hasn't
had the pointer to the child adjusted, removed, whatever...

4. Then: we get the lock on the playlist, we have a pointer to the parent
and have to return data about the child's number of teeth. It doesn't help
us to hold a lock! The parent still exists, but the child not, and the
parent's pointer to the child is not valid! we dereference the pointer ->
bang! segfault! isn't it so?? or if we are very very lucky we might get away
without the segfault, only corrupted data, but I wouldn't count on that one
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090814/9bcb8c98/attachment.html>

More information about the vlc-devel mailing list