|
From: Xiaowei J. <xj...@vm...> - 2007-07-19 22:42:58
|
Hi there, I tried to use valgrind to detect memory leaks for my program, which is = multithreaded and uses locks to protect shared resources. I use my own = lock/unlock function and do some asserts there. It works pretty fine for = normal runs. However, when I was running the program with valgrind, I = saw non-determinsitc assertion failure from the lock/unlock functions, = which complains either the lock varaible is still 0, or the owner of the = lock is not current thread after lock being successfully acquired, even = trying to unlock a lock which is not locked at all. This might indicates = the lock doesn't work and results in a lot of race conditions. I read the valgrind manual, it says valgrind schedules concurrent = threads in round-robin fashion. Can I assume atomic instructions are not = required here for acquiring the lock? Can someone help me out of this = issue or give me some hints? Thanks in advance, Xiaowei |
|
From: Nicholas N. <nj...@cs...> - 2007-07-19 22:46:00
|
On Thu, 19 Jul 2007, Xiaowei Jiang wrote: > I tried to use valgrind to detect memory leaks for my program, which is > multithreaded and uses locks to protect shared resources. I use my own > lock/unlock function and do some asserts there. It works pretty fine for > normal runs. However, when I was running the program with valgrind, I saw > non-determinsitc assertion failure from the lock/unlock functions, which > complains either the lock varaible is still 0, or the owner of the lock is > not current thread after lock being successfully acquired, even trying to > unlock a lock which is not locked at all. This might indicates the lock > doesn't work and results in a lot of race conditions. > > I read the valgrind manual, it says valgrind schedules concurrent threads > in round-robin fashion. Can I assume atomic instructions are not required > here for acquiring the lock? Can someone help me out of this issue or give > me some hints? Valgrind serialises thread execution, so that only one thread runs at a time. Perhaps that information might be of some help? Nick |
|
From: Xiaowei J. <xj...@vm...> - 2007-07-20 22:00:35
|
Thanks for your reply. So if valgrind picks up one thread to run at a time, in that sense atomicity should not be required while acquiring the lock. Is it right? What I've observed in my program is, no matter I use atomic instructions or normal instructions for lock acqusition, I saw race conditions in the program under valgrind, which never exists without valgrind. Can anyone give me some hint or suggestions? Thanks in advance, Xiaowei ----- Original Message ----- From: "Nicholas Nethercote" <nj...@cs...> To: "Xiaowei Jiang" <xj...@vm...> Cc: <val...@li...> Sent: Thursday, July 19, 2007 3:46 PM Subject: Re: [Valgrind-users] Valgrind on multithreaded program > On Thu, 19 Jul 2007, Xiaowei Jiang wrote: > >> I tried to use valgrind to detect memory leaks for my program, which is >> multithreaded and uses locks to protect shared resources. I use my own >> lock/unlock function and do some asserts there. It works pretty fine for >> normal runs. However, when I was running the program with valgrind, I saw >> non-determinsitc assertion failure from the lock/unlock functions, which >> complains either the lock varaible is still 0, or the owner of the lock >> is not current thread after lock being successfully acquired, even trying >> to unlock a lock which is not locked at all. This might indicates the >> lock doesn't work and results in a lot of race conditions. >> >> I read the valgrind manual, it says valgrind schedules concurrent threads >> in round-robin fashion. Can I assume atomic instructions are not required >> here for acquiring the lock? Can someone help me out of this issue or >> give me some hints? > > Valgrind serialises thread execution, so that only one thread runs at a > time. Perhaps that information might be of some help? > > Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-07-21 01:28:34
|
On Fri, 20 Jul 2007, Xiaowei Jiang wrote: > So if valgrind picks up one thread to run at a time, in that sense atomicity > should not be required while acquiring the lock. Is it right? If I understand correctly, yes. > What I've observed in my program is, no matter I use atomic instructions or > normal instructions for lock acqusition, I saw race conditions in the > program under valgrind, which never exists without valgrind. Some races can still occur even if your program runs single-threaded, I believe. And things happen a bit differently under Valgrind (memory layout is a bit different, thread switching order will be a bit different). So that could explain some differences. Nick |
|
From: Stephane H. <sho...@ni...> - 2007-07-21 17:54:55
|
valgrind executes one thread at a time but switches between threads very quickly, faster than a single cpu/core machine would. you could also have a memory overwrite on the lock itself, or a bad initialization. I suggest making a log of all the locks/unlocks of each mutex including thread IDs then check for inconsistencies (a lock that was aquired twice without an unlock in between might uncover some memory overwrites) On Friday 20 July 2007 18:00, Xiaowei Jiang wrote: > Thanks for your reply. > > So if valgrind picks up one thread to run at a time, in that sense > atomicity should not be required while acquiring the lock. Is it right? > > What I've observed in my program is, no matter I use atomic instructions or > normal instructions for lock acqusition, I saw race conditions in the > program under valgrind, which never exists without valgrind. > > Can anyone give me some hint or suggestions? > > Thanks in advance, > Xiaowei > > ----- Original Message ----- > From: "Nicholas Nethercote" <nj...@cs...> > To: "Xiaowei Jiang" <xj...@vm...> > Cc: <val...@li...> > Sent: Thursday, July 19, 2007 3:46 PM > Subject: Re: [Valgrind-users] Valgrind on multithreaded program > > > On Thu, 19 Jul 2007, Xiaowei Jiang wrote: > >> I tried to use valgrind to detect memory leaks for my program, which is > >> multithreaded and uses locks to protect shared resources. I use my own > >> lock/unlock function and do some asserts there. It works pretty fine for > >> normal runs. However, when I was running the program with valgrind, I > >> saw non-determinsitc assertion failure from the lock/unlock functions, > >> which complains either the lock varaible is still 0, or the owner of the > >> lock is not current thread after lock being successfully acquired, even > >> trying to unlock a lock which is not locked at all. This might indicates > >> the lock doesn't work and results in a lot of race conditions. > >> > >> I read the valgrind manual, it says valgrind schedules concurrent > >> threads in round-robin fashion. Can I assume atomic instructions are not > >> required here for acquiring the lock? Can someone help me out of this > >> issue or give me some hints? > > > > Valgrind serialises thread execution, so that only one thread runs at a > > time. Perhaps that information might be of some help? > > > > Nick > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Stephane Hockenhull SSC-Studios.com |