|
From: Konstantin S. <kon...@gm...> - 2007-11-08 12:30:16
|
Dear valgrind developers, I have a question regarding thrcheck. If thrcheck detects a race it prints something like this: ==30205== Possible data race during write of size 4 at 0x5C52028 ==30205== at 0x80484D7: main (heap_race.c:18) ==30205== Old state: owned exclusively by thread #2 ==30205== New state: shared-modified by threads #1, #2 ==30205== Reason: this thread, #1, holds no locks at all So, the debug info gives us the line of code where the *second* access to this memory has happened. But it does not give any information about the *first* access. Of course, in a simple program the first access could be found by just looking at the code. If the accessed memory is global/static variable, we can run the program under gdb with watchpoint. However, if the memory in question is dynamically allocated and buried deep inside some structures, we are in trouble. Do you have any suggestion how to find the first access in a general case? I assume that valgrind can not track history of accesses to all memory addresses with corresponding stacks. Too expensive. May be it can keep such history for those addresses where a race has been detected? But it will not help if the memory was accessed only once in the first thread. Another way is to run valgrind twice -- the first run will act as usual and the second run will take the report of the first one and treat addresses in the report specially. Though, of course, running valgrind twice is not fun. What I would like to see is: ==30205== Possible data race during write of size 4 at 0x5C52028 ==30205== at 0x80484D7: main (heap_race.c:18) ==30205== Old state: owned exclusively by thread #2 ==30205== New state: shared-modified by threads #1, #2 ==30205== Reason: this thread, #1, holds no locks at all *==30205== One of the previous accesses to 0x5C52028 in thread #2 was ==30205== at 0x1234567: somewhere (somewhere.c:123) ==30205== by 0x80484D7: main (heap_race.c:18) * Actually, these two approaches are complimentary. Ideas? Suggestions? Thanks, --kcc |
|
From: Julian S. <js...@ac...> - 2007-11-08 12:55:25
|
> I assume that valgrind can not track history of accesses to all memory > addresses with corresponding stacks. Too expensive. True. > May be it can keep such history for those addresses where a race has been > detected? That could be possible at reasonable cost. > But it will not help if the memory was accessed only once in the first > thread. True. Oh well. > Another way is to run valgrind twice -- the first run will act as usual and > the second run will take the report of the first one and treat addresses in > the report specially. Though, of course, running valgrind twice is not fun. > What I would like to see is: > ==30205== Possible data race during write of size 4 at 0x5C52028 You can sort-of do this already. Rerun with --trace-addr=0x5C52028 and --trace-level=1. This will give you a 1-line summary for each access to 0x5C52028. At --trace-level=2 you get a complete stack trace. I would be interested to know if that is useful. J |
|
From: Konstantin S. <kon...@gm...> - 2007-11-09 11:54:50
|
> I would be interested to know if that is useful. It works and it is certainly useful! Few more questions: - as I see, the interceptors for pthread spin locks are not implemented yet. Is that a principal limitation or just a matter of time? - If a spin lock/unlock routines are inlined by the compiler there is no way for valgrind to intercept them, right? Need to force the compiler not to inline them... - How to show file names with full path in thrcheck's output? Thanks! --kcc On Nov 8, 2007 3:54 PM, Julian Seward <js...@ac...> wrote: > > > I assume that valgrind can not track history of accesses to all memory > > addresses with corresponding stacks. Too expensive. > > True. > > > May be it can keep such history for those addresses where a race has been > > detected? > > That could be possible at reasonable cost. > > > But it will not help if the memory was accessed only once in the first > > thread. > > True. Oh well. > > > Another way is to run valgrind twice -- the first run will act as usual and > > the second run will take the report of the first one and treat addresses in > > the report specially. Though, of course, running valgrind twice is not fun. > > > What I would like to see is: > > ==30205== Possible data race during write of size 4 at 0x5C52028 > > You can sort-of do this already. Rerun with --trace-addr=0x5C52028 > and --trace-level=1. This will give you a 1-line summary for each > access to 0x5C52028. At --trace-level=2 you get a complete stack > trace. > > I would be interested to know if that is useful. > > J > |
|
From: Julian S. <js...@ac...> - 2007-11-09 12:15:40
|
On Friday 09 November 2007 12:54, Konstantin Serebryany wrote: > > I would be interested to know if that is useful. > It works and it is certainly useful! Good. Thanks. > - as I see, the interceptors for pthread spin locks are not > implemented yet. Is that a principal limitation or just a matter of > time? Just a matter of time. > - If a spin lock/unlock routines are inlined by the compiler there is > no way for valgrind to intercept them, right? That's true; but it looks like they are not inlined: $ nm /lib/libpthread-2.5.so | grep spin 0000000000009e30 T pthread_spin_destroy 0000000000009e80 T pthread_spin_init 0000000000009e40 T pthread_spin_lock 0000000000009e60 T pthread_spin_trylock 0000000000009e80 T pthread_spin_unlock $ nm /lib64/libpthread-2.5.so | grep spin 000000000000ae50 T pthread_spin_destroy 000000000000aea0 T pthread_spin_init 000000000000ae60 T pthread_spin_lock 000000000000ae80 T pthread_spin_trylock 000000000000aea0 T pthread_spin_unlock so you should be able to easily make wrappers for them starting from the ones for pthread_mutex_*. > - How to show file names with full path in thrcheck's output? I think Nick and/or Josef know about this. I remember that a change was committed to trunk, which makes this work. When Thrcheck is merged to trunk (soon), then it will get that same functionality. J |
|
From: Nicholas N. <nj...@cs...> - 2007-11-09 22:37:30
|
On Fri, 9 Nov 2007, Julian Seward wrote: >> - How to show file names with full path in thrcheck's output? > > I think Nick and/or Josef know about this. I remember that a change > was committed to trunk, which makes this work. When Thrcheck is merged > to trunk (soon), then it will get that same functionality. Yes, you have to use VG_(get_filename_linenum). (Strangely enough, VG_(get_filename) doesn't get the directory name.) N |