|
From: Bart V. A. <bar...@gm...> - 2006-03-02 10:55:11
|
Hello,
Has anyone experience with tracking pthread-related events as
emitted by the Valgrind core ? It looks like Valgrind 3.1.0's core
only notifies my tool about thread_create() events, and no other
events. I have verified with gdb that all of pthread_create(),
pthread_join(), pthread_mutex_lock() and pthread_mutex_unlock() are
called multiple times by the client application.
The following code is present drd_pre_clo_init():
VG_(track_pre_mutex_lock) (drd_pre_mutex_lock);
VG_(track_post_mutex_lock) (drd_post_mutex_lock);
VG_(track_post_mutex_unlock) (drd_post_mutex_unlock);
VG_(track_post_thread_create)(drd_post_thread_create);
VG_(track_post_thread_join) (drd_post_thread_join);
Shell output (the drd_... functions currently only print their name
and arguments, and the test program creates two threads):
$ inst/bin/valgrind --tool=3Ddrd ~/stc/build/posix/debug/stc-test 3 2>&1
| grep ^drd
drd_post_thread_create tid =3D 0, child =3D 1
drd_post_thread_create tid =3D 1, child =3D 2
drd_post_thread_create tid =3D 1, child =3D 3
|
|
From: Julian S. <js...@ac...> - 2006-03-02 11:22:11
|
You really need to be using the svn trunk for this, not 3.1.0. If you uncomment the #if 0'd stuff at the bottom of vg_preloaded.c then vg should at least intercept some of the pthread_* calls. However there is still a missing link, which is how to get from these wrappers (which run on the simulated cpu) to notifying your drd tool of thread events. What thread events do you need your tool to be notified of? J On Thursday 02 March 2006 10:55, Bart Van Assche wrote: > Hello, > > Has anyone experience with tracking pthread-related events as > emitted by the Valgrind core ? It looks like Valgrind 3.1.0's core > only notifies my tool about thread_create() events, and no other > events. I have verified with gdb that all of pthread_create(), > pthread_join(), pthread_mutex_lock() and pthread_mutex_unlock() are > called multiple times by the client application. > > The following code is present drd_pre_clo_init(): > > VG_(track_pre_mutex_lock) (drd_pre_mutex_lock); > VG_(track_post_mutex_lock) (drd_post_mutex_lock); > VG_(track_post_mutex_unlock) (drd_post_mutex_unlock); > VG_(track_post_thread_create)(drd_post_thread_create); > VG_(track_post_thread_join) (drd_post_thread_join); > > Shell output (the drd_... functions currently only print their name > and arguments, and the test program creates two threads): > $ inst/bin/valgrind --tool=drd ~/stc/build/posix/debug/stc-test 3 2>&1 > > | grep ^drd > > drd_post_thread_create tid = 0, child = 1 > drd_post_thread_create tid = 1, child = 2 > drd_post_thread_create tid = 1, child = 3 > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <to...@co...> - 2006-03-02 11:22:52
|
In message <e2e...@ma...>
Bart Van Assche <bar...@gm...> wrote:
> Has anyone experience with tracking pthread-related events as
> emitted by the Valgrind core ? It looks like Valgrind 3.1.0's core
> only notifies my tool about thread_create() events, and no other
> events. I have verified with gdb that all of pthread_create(),
> pthread_join(), pthread_mutex_lock() and pthread_mutex_unlock() are
> called multiple times by the client application.
The thread tracking stuff is not really working at the moment - hence
the reason that helgrind is not working.
We do have the technology now, and I did start work on fixing it, but
it is by no means complete.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-02 11:25:11
|
> On Thursday 02 March 2006 11:22, Tom Hughes wrote: > > We do have the technology now, and I did start work on fixing it, but > it is by no means complete. How far did you get? Do you have any patches lying around? J |
|
From: Julian S. <js...@ac...> - 2006-03-05 16:57:35
|
> By this time I obtained a copy from the trunk and added (locally) the
> 'drd' tool to the trunk. ('drd' is short for data race detection -- is this
> a good name ?)
Seems as good as any.
> I tried to uncomment the three functions at the end of
> coregrind/vg_preloaded.c, but I got the following compiler errors when I
> tried this:
> vg_preloaded.c:90: warning: implicit declaration of function
> 'VALGRIND_GET_NRADDR'
> vg_preloaded.c:93: error: invalid initializer
> vg_preloaded.c: In function
> '_vgwZZ_libpthreadZdsoZd0_pthreadZumutexZulock': vg_preloaded.c:105:
> warning: initialization from incompatible pointer type vg_preloaded.c:108:
> error: invalid initializer
> vg_preloaded.c: In function
> '_vgwZZ_libpthreadZdsoZd0_pthreadZumutexZuunlock':
> vg_preloaded.c:120: warning: initialization from incompatible pointer type
> vg_preloaded.c:124: error: invalid initializer
Yeh, that code is a bit out of date. The patch I sent earlier today
fixes that (you need to change "void* fn" to "OrigFn fn").
> - Eraser attempts to verify a locking discipline, that is, whether or not
> there is a mutex associated with each shared variable and that this mutex
> is locked every time the variable is accessed.
> - DIOTA does not attempt to do any verifications at the program level, but
> only verifies one particular execution of a program. It verifies whether
> accesses to the same variable by different threads are ordered by
> synchronization actions.
They sound very similar. I guess there are details ..
> So the short answer is: I'd like to be informed about every event that
> imposes an ordering of events between threads. The DIOTA tool instruments
> the following calls:
> - pthread_create(), pthread_join(), pthread_exit().
> - pthread_mutex_lock(), pthread_mutex_unlock(), pthread_mutex_trylock().
> - pthread_cond_wait(), pthread_cond_timedwait().
> - sem_wait(), sem_post(), sem_trywait().
> - pthread_barrier_wait().
>
> The following are IMHO also interesting:
> - pthread_rwlock_rdlock(), pthread_rwlock_tryrdlock(),
> pthread_rwlock_trywrlock(), pthread_rwlock_unlock(),
> pthread_rwlock_wrlock().
> - pthread_spin_lock(), pthread_spin_trylock(), pthread_spin_unlock().
>
> Is it possible to send notifications for all these functions ?
In principle yes. As per my earlier posting you should be able to hack
up wrappers and notifications for any of them yourself; however I
think it would be good to get the thing to work well enough so we can
evaluate it with just the basics (lock, unlock, create, join).
> By the way, do you have any idea which algorithm is implemented in Intel's
> Thread Checker (part of VTune) ?
Absolutely no idea.
> I have used VTune for testing a
> cross-platform threading library, and every time VTune reported a data race
> it was a real one.
That's impressive.
J
|
|
From: Bart V. A. <bar...@gm...> - 2006-03-07 19:31:18
|
On 3/5/06, Julian Seward <js...@ac...> wrote: > > So the short answer is: I'd like to be informed about every event that > > imposes an ordering of events between threads. The DIOTA tool instrumen= ts > > the following calls: > > - pthread_create(), pthread_join(), pthread_exit(). > > - pthread_mutex_lock(), pthread_mutex_unlock(), pthread_mutex_trylock()= . > > - pthread_cond_wait(), pthread_cond_timedwait(). > > - sem_wait(), sem_post(), sem_trywait(). > > - pthread_barrier_wait(). > > > > The following are IMHO also interesting: > > - pthread_rwlock_rdlock(), pthread_rwlock_tryrdlock(), > > pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), > > pthread_rwlock_wrlock(). > > - pthread_spin_lock(), pthread_spin_trylock(), pthread_spin_unlock(). > > > > Is it possible to send notifications for all these functions ? > > In principle yes. As per my earlier posting you should be able to hack > up wrappers and notifications for any of them yourself; however I > think it would be good to get the thing to work well enough so we can > evaluate it with just the basics (lock, unlock, create, join). OK, as soon as I have the time I will work on the wrappers and try to get the drd tool working with mutex locking, unlocking and with thread creation / termination. |