Re: [Valgrind-users] valgrind pthreads mutex bug

[Andraz T. <And...@gu...>]

V pet, 30.05.2003 ob 02:32, je Jeremy Fitzhardinge poslal(a):
> On Thu, 2003-05-29 at 17:01, Andraz Tori wrote: 
> > Thanks, I didn't know that. De facto this is vaild behaviour in
> > pthreads... Everything works as expected if valgrind is not run...
> > 
> > If this is true than mutexes are useless for interthread synchronisation
> > of 'data ready' states?
> They're already useless for that; I'm guessing you really want to be
> using condition variables, which have the behaviour you're looking
> for.  With any luck, they synchronization code is only in one or two
> places...

I am afraid it is not so easy... Cinelerra is a strange beast...

kocka:/home/minmax/progs/hvirtual-1.1.6/cinelerra# grep Mutex *.[Ch]|wc
-l
    104

approx half of these mutexes is being used for synchronisation like this
and this does not include plugins ... :)

The problem is that main maintainer has... mildly said ... strange
attitutde towards any external work done. to my experience he would
never accept external patch to fix this. 

Heh... my other question is... would it be possible to modify valgrind
so it would not report memory leaks that occured just once (at the same
code line)?

Again, main maintainer isn't willing to make deletions on exit (even
when provided with a proper patch) so i am looking for some other
solution to be able to find just leaks that are done repeatedly while
using the program. There are houndrets of one-time leaks, so writing
supressions for all of them is out of the question...

> > > The bug is that Valgrind should flag this as an error.
> > 
> > The whole cinelerra (quite a huge program) is based upon this kind of
> > behaviour. It uses mutexes in order to synchronize 'data delivery':
> That's exactly what a condvar is for. 

Thanks ! But aren't condvars slower than mutexes? (i would imagine)

> > So my question is... would it be possible for Valgrind to support this
> > bugous behaviour by some switch or something?
> If you come up with a patch we can look at it.  But I think your time
> would be better spent fixing the code: what you're asking is
> equivalent to "but my program always uses memory after it has been
> freed, and it works fine without Valgrind". 

I would gladly fix the code, but i am afraid it wont be accepted into
main branch of cinelerra, which means the work would be useless. At
least to my experience. So I just try to work on trivial bugs, because
anything nontrivial isn't accepted.

> > The problem is that cinelerra works just fine if it is run without
> > valgrind... 
> Oh yes. Have you tried it with NPTL?

no, I am already afraid.  :)

but the bottom line: why don't neither pthreads neither valgrind return
the error on the unlock call... Valgrind reports a warning, but call
still returns success (perror says nothing)... even if it is obvious
there was a failure.

I did create error checking pthread mutex (as you suggest in your next
message)..  it is not reporting errors.

the unlock is done with:
	printf("Unlocking mutex: %p\n", &mutex);
	if(pthread_mutex_unlock(&mutex)) {perror("Mutex::unlock");

here it is, relevant part of the log file...
mutex 0x41a9f2a4 is being unlocked, and perror says successefuly, on the
next usage it blocks on lock...

Unlocking mutex: 0x41a9f2a4
--24562-- PTHREAD[25]: pthread_mutex_unlock	 mx 0x41A9F2A4 ...
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock     mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock     mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_key_validate    key 0x3
--24562-- PTHREAD[25]: pthread_getspecific_ptr
--24562-- PTHREAD[25]: pthread_mutex_lock       mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock  	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409BB1F0 ...
--24562-- PTHREAD[25]: pthread_mutex_lock  	mx 0x409C28C8 ...
--24562-- PTHREAD[25]: pthread_mutex_unlock	mx 0x409C28C8 ...
Mutex::unlock: Success   
Locking mutex: 0x41a9f2a4
--24562-- PTHREAD[25]: pthread_mutex_lock 	 mx 0x41A9F2A4 ...   
--24562-- PTHREAD[25]: pthread_mutex_lock 	 mx 0x41A9F2A4: BLOCK


bye
andraz