Provider update deadlock in DviSubscription::PropertiesInitialised
|
03-06-2013, 08:56 AM
(This post was last modified: 03-06-2013 01:29 PM by lpeter.)
Post: #1
|
|||
|
|||
Provider update deadlock in DviSubscription::PropertiesInitialised
Hi,
I'm trying to write a simple renderer based on ohNet, but I hit the wall. It locks up after a few seconds after it starts playing a track. Little debugging showed me that two threads gets in a deadlock. One them is the thread tries to update a provider property from a Timer callback, the other one is ohNet thread that tries to cancel a Timer. Detailed call stack : Thread 1: Callback thread from timer already acquired iCallbackMutex in TimerManager and tries to acquire iLock in DviSubscription Code: OpenHome::Os::MutexLock(void * aMutex) Line 53 C++ Thread 2: Internal ohNet thread that already acquired iLock in DviSubscription and tries to acquire iCallbackMutex in TimerManager: Code: OpenHome::Os::MutexLock(void * aMutex) Line 53 C++ It is not clear to me weather this az undocumented feature that provider properties should not be updated in a Timer callback, or it is a TimerManager bug... Br, Peter |
|||
03-06-2013, 03:20 PM
(This post was last modified: 03-06-2013 03:20 PM by simonc.)
Post: #2
|
|||
|
|||
RE: Provider update deadlock in DviSubscription::PropertiesInitialised
(03-06-2013 08:56 AM)lpeter Wrote: I'm trying to write a simple renderer based on ohNet, but I hit the wall. It locks up after a few seconds after it starts playing a track. Thanks for the detailed report! This was a bug. I hope I've fixed it locally. The changes should make it onto github this evening. |
|||
05-06-2013, 10:54 AM
Post: #3
|
|||
|
|||
RE: Provider update deadlock in DviSubscription::PropertiesInitialised | |||
05-06-2013, 10:57 AM
(This post was last modified: 05-06-2013 10:57 AM by simonc.)
Post: #4
|
|||
|
|||
RE: Provider update deadlock in DviSubscription::PropertiesInitialised
(05-06-2013 10:54 AM)lpeter Wrote: I tested the patch and it fixed the deadlock issue. Thanks. Thanks, good to hear its working. (05-06-2013 10:54 AM)lpeter Wrote: ...strange, but it appeared on github only yesterday evening. We run an automated set of builds/tests each evening and only push to github if these pass. We had a problem with our Mac build slave a couple of days ago which caused a build to fail and so the code push to be deferred. |
|||
« Next Oldest | Next Newest »
|