I read, I understand. I don't know enough about Qt to add to discussion.
Kudos on tracking this down.
On Wed, Jul 2, 2008 at 1:25 AM, Russell Ryan <[EMAIL PROTECTED]> wrote:
> hey guys,
>
> so after playing with the bug last night, here's the recap:
>
> One place that was causing a side effect of the issue was in
> midiledcontrol.cpp, it was using a control object without seeing if
> ControlObject::getControl returned null. In this case, it was returning
> null, but for a control like ("[Channel1]", "play"), something that
> definitely exists. We made it test for null, but the root cause was
> still unknown.
>
> We scratched our heads a bit, and looked at getControl -- it uses a
> Q3PtrList. After printlining the entry and exit to getControl, we found
> this: http://pastebin.com/m308ae53f
>
> Basically, the problem goes hand in hand with a double 'ENTER'. It turns
> out the line:
>
> for(c=m_sqList.begin(); c; c=m_sqList.next())
>
> Implies that the Q3PtrList keeps track of the iterator internally, which
> means it's definitely not safe for two threads to iterate at the same
> time. The reason that it's missing something that exists like 'play' is
> that if both threads hit their m_sqList.next() call at the same time,
> then whichever 'current' node won the race then gets incremented twice.
>
> It's also is not supposed to be iterated while appended or removed from,
> so the ControlObject creation and destruction needs locking too.
>
> So we probably need a lock at least on append and remove from this list.
> If we upgrade from Q3PtrList to QList, we can use QList::const_iterator
> which returns an iterator object that will not be screwed up by other
> threads iterating the object. The docs say an iterator becomes undefined
> if you append or remove while using it though, so technically we could
> have an issue if we append to the list while iterating. -- sketchy
>
> Adding a lock to getControl, append, and remove on my branch caused it
> to go away. So that's good. I'm also curious about what other subtle
> bugs this might be linked to. We've only encountered one of the three
> races that exist here. The other two are iterate / append and
> iterate/destroy (and I guess, append/destroy, and destroy/destroy). It's
> definitely a longshot, but some of those 'not exiting cleanly' style
> bugs might be caused by something like a two controlobjects being
> destroyed at once so their remove calls to m_sqList conflict and trash
> the datastructure. shrug.. it's nice to dream right :)
>
> Moving to QList seems good regardless (because const_iterator is faster,
> it's newer, get rid of QT3 stuff, etc) So the question remaining is
> whether or not to lock inside of getControl...
>
>
> RJ
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
