|
From: Stefan S. <en...@ho...> - 2011-10-07 12:40:38
|
On 10/06/2011 11:28 AM, WAROQUIERS Philippe wrote: >> ... >> 2243 GST_OBJECT_UNLOCK (pad); >> 2244 result = GST_PAD_GETCAPSFUNC (pad) (pad); >> 2245 GST_OBJECT_LOCK (pad); >> >> The first two snippets use the same lock order and the third snipped >> temporarily releases a lock. > As line 2243 unlocks pad, there must be another place where pad is > locked. > This other place might intervene in the cycle of lock acquisition. > I don't think so. The code is not related. >> At the point where the code locks up, I get no complaint from helgrind. >> Will try my luck with building 3.7 now. > With 3.7.0 SVN, you can try the debugger (cfr --vgdb-error=0) to > understand the deadlock under memcheck. Yes, vgdb server worked great and I know the 2 places involved in the deadlock now. Thanks for your work on the tool! > You might also try again with helgrind (Julian did several improvements > in helgrind, in particular improving the error messages). I am still not convinced. I get lots of warnings from helgrind. Some of them make sense, allthough I found many that cause no harm in practise. Stefan > Philippe > > ____ > > This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. > > Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. > > Any views expressed in this message are those of the sender. |