|
From: Julian S. <js...@ac...> - 2006-08-27 01:37:32
|
I tried starting OpenOffice on drd, and it reported a bunch of races, and after a while makes no forward progress but uses 100% cpu and eats memory. Maybe this is related to the knode-hang-at-exit I reported just now. I have a wider question. I guess it is critical, for avoiding false errors, that the tool sees all synchronisation points, else it will be comparing segments that it should not compare, and so may reporting false errors. So the question is: how do we know what subset of the pthread_ functions is it necessary to intercept in order to make the tool reasonably robust? I see you intercept a few .. create, join, mutex_init, mutex_destroy, mutex_lock, mutex_unlock, mutex_trylock, cond_wait but surely there are a lot more that need to be intercepted? Now that we have a basic framework, how much of that pthread intercept stuff can be imported from Diota (Diota is GPLd, right?) J On Saturday 26 August 2006 17:22, Bart Van Assche wrote: > Hello, > > I have applied the following changes to the drd prototype: > - Fixed huge memory leak (thanks Julian !). > - Support for Ist_Dirty with side effects (Julian's patch). > - Cleanup of error reporting. > - Disabled malloc()/free() and friends wrappers. > - Removed #include "drd/drd_clientreq.h" from coregrind/vg_preloaded.c. > - Various small changes. > > Source code: > http://home.scarlet.be/~bvassche/drd/valgrind-6012.patch > http://home.scarlet.be/~bvassche/drd/valgrind-6012-drd-2006-08-26.tar.bz2 > > What I consider now as a priority is to get drd working on pth_cvsimple. > Anyone any idea what the behavior of Valgrind is when a wrapper is defined > in vg_preloaded.c for a function that is defined in multiple shared > libraries (e.g. pthread_mutex_lock()) ? |