|
From: David L. <dav...@te...> - 2004-06-25 15:05:36
|
Thanks, Tom! That was just the hint I needed.
I changed g++'s parameters for linking from the old app to the new app.
When things used to work, I used '-lpthread' to bring in the pthread
libs. I needed some stuff from librt, so I changed the parameter to
'-lrt', since librt brings in libpthread. This implicit linking of
libpthread is what broke Valgrind.
Here a small demo of the problem:
[dlee@lindb1 cpp]$ cat killgrind.c
#include <pthread.h>
#include <semaphore.h>
#include <stdio.h>
sem_t rdSem;
void *reader(void *p)
{
sem_wait(&rdSem);
printf("%s\n", __FUNCTION__);
}
int push()
{
sem_post(&rdSem);
}
void dbg()
{
// for no other reason than to force Valgrind to print
pthread_attr_t attr =3D {};
struct sched_param param =3D {};
pthread_attr_init(&attr); =20
pthread_attr_setschedparam(&attr, ¶m);
}
int main()
{
pthread_t thread;
dbg();
sem_init(&rdSem, 0, 0);
pthread_create(&thread, 0, reader, 0);
sleep(1); // for bug to happen, sem_wait has to wait
push();
=20
pthread_join(thread, 0);
printf("fin\n");
}
//EOF
[dlee@lindb1 cpp]$ gcc killgrind.c -o killgrind-pthread -lrt -lpthread
[dlee@lindb1 cpp]$ gcc killgrind.c -o killgrind-rt -lrt
[dlee@lindb1 cpp]$ ./killgrind-pthread=20
reader
Fin
[dlee@lindb1 cpp]$ ./killgrind-rt=20
reader
fin
[dlee@lindb1 cpp]$ Valgrind --tool=3Dmemcheck --trace-children=3Dyes
./killgrind-pthread=20
=3D=3D4892=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D4892=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D4892=3D=3D Using valgrind-2.1.1, a program supervision framework =
for
x86-linux.
=3D=3D4892=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D4892=3D=3D For more details, rerun with: -v
=3D=3D4892=3D=3D=20
=3D=3D4892=3D=3D warning: Valgrind's pthread_attr_setschedparam does =
nothing
=3D=3D4892=3D=3D (scheduling not changeable)
=3D=3D4892=3D=3D your program may misbehave as a result
reader
fin
=3D=3D4892=3D=3D=20
=3D=3D4892=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 =
from 1)
=3D=3D4892=3D=3D malloc/free: in use at exit: 216 bytes in 2 blocks.
=3D=3D4892=3D=3D malloc/free: 3 allocs, 1 frees, 240 bytes allocated.
=3D=3D4892=3D=3D For a detailed leak analysis, rerun with: =
--leak-check=3Dyes
=3D=3D4892=3D=3D For counts of detected errors, rerun with: -v
[dlee@lindb1 cpp]$ Valgrind --tool=3Dmemcheck --trace-children=3Dyes
./killgrind-rt
=3D=3D4895=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D4895=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D4895=3D=3D Using valgrind-2.1.1, a program supervision framework =
for
x86-linux.
=3D=3D4895=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D4895=3D=3D For more details, rerun with: -v
=3D=3D4895=3D=3D=20
At this point, CPU utilization goes to 100% and Valgrind goes bye-bye.
After some more twiddling, I found the root cause of the problem. When
libpthread is linked in implicitly, it is linked after libc. Normally
it's linked before libc. Valgrind is apparently sensitive to this
linking order.
Thanks!
dave
<><
|