|
From: Andrey U. <and...@gm...> - 2009-03-10 17:06:54
|
Hi, all! I`m trying to solve one unclear issue in a fork of asterisk 1.2 that is presumably caused by mutexes misuse. So i run it under the great tool Helgrind, and see messages like 'lock order "0x5F6291C before 0x40D1850" violated'. And there`s plenty of mutexes with different identifications (i mean these 0x...), and it`s hard to figure out their names. Is there a known way of determination of some kind of humanic name of mutex? Thanks in advance. -- Andrey Utkin |
|
From: Julian S. <js...@ac...> - 2009-03-12 12:05:59
|
On Tuesday 10 March 2009, Andrey Utkin wrote: > Hi, all! > I`m trying to solve one unclear issue in a fork of asterisk 1.2 that is > presumably caused by mutexes misuse. > So i run it under the great tool Helgrind, and see messages like 'lock > order "0x5F6291C before 0x40D1850" violated'. > And there`s plenty of mutexes with different identifications (i mean these > 0x...), and it`s hard to figure out their names. Is there a known way of > determination of some kind of humanic name of mutex? Maybe it's not so hard .. Helgrind does have that information (somewhere). (and yes, it would be good to show it) What you can do: * file a bug report at www.valgrind.org, so this is not forgotten, and wait some months for us to have enough time to fix it, or * hack something up yourself: hg_main.c:132 declares a linked list of 'Lock' structures: /* Admin linked list of Locks */ static Lock* admin_locks = NULL; You need to scan through this list, and find the Lock whose .guestaddr field equals the location shown in the error message (0x5F6291C etc). When you have found the right Lock, then do VG_(pp_ExeContext) on the .appeared_at field -- this gives you a stack trace where Helgrind first noticed that the lock existed. And you need to do this in the 'case XE_LockOrder' in HG_(pp_Error) in hg_errors.c. The two lock addresses are xe->XE.LockOrder.before_ga xe->XE.LockOrder.after_ga respectively. I hope that makes sense. J |