|
From: Dennis L. <pla...@in...> - 2004-05-14 22:09:31
|
Hi, I've tried to run a rather complex software with valgrind that uses some threads, and sends quite a lot of signals between those threads via kill() as well as pthread_kill(), and sometimes even to itself. (Hey, don't ask me why, I have not designed it, but we need to live with it, its really very complex, and currently not possible to remove all this stuff). It furthermore also relies on the old Linux behaviours that each thread has its own pid, so it can send signals all around. But when running with valgrind, it very soon stops, beeing "killed" by User Defined Signal 1. My question now is, is it possible to use valgrind so that it really delivers those signals to the parts of the program ? I have tried several options, none seems to improve behaviour. greets Dennis |
|
From: David E. <tw...@us...> - 2004-05-15 10:08:28
|
On Sat, 2004-05-15 at 00:09, Dennis Lubert wrote:
> Hi,
>
> I've tried to run a rather complex software with valgrind that uses some
> threads, and sends quite a lot of signals between those threads via
> kill() as well as pthread_kill(), and sometimes even to itself. (Hey,
> don't ask me why, I have not designed it, but we need to live with it,
> its really very complex, and currently not possible to remove all this
> stuff). It furthermore also relies on the old Linux behaviours that each
> thread has its own pid, so it can send signals all around.
> But when running with valgrind, it very soon stops, beeing "killed" by
> User Defined Signal 1. My question now is, is it possible to use
> valgrind so that it really delivers those signals to the parts of the
> program ? I have tried several options, none seems to improve behaviour.
I think that the getpid() function returns the same PID for all threads
when using valgrind. If you need to live with your complex software, you
probably also have to live without valgrind...
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Paul P. <pa...@pa...> - 2004-05-17 15:30:19
|
>>>>> On Sat, 15 May 2004 12:08:12 +0200, David Eriksson <tw...@us...> said:
> On Sat, 2004-05-15 at 00:09, Dennis Lubert wrote:
>>
>> I've tried to run a rather complex software with valgrind that uses some
>> threads, and sends quite a lot of signals between those threads via
>> kill() as well as pthread_kill(), and sometimes even to itself. [...]
> I think that the getpid() function returns the same PID for all threads
> when using valgrind. If you need to live with your complex software, you
> probably also have to live without valgrind...
But not necessarily without a "valgrind-like" tool.
You may wish to check out Chaperon, which doesn't "munge" on getpid().
Chaperon is part of Insure++ (http://www.parasoft.com/insure).
Cheers,
--
Paul Pluzhnikov pa...@pa...
|
|
From: Dennis L. <pla...@in...> - 2004-05-17 15:51:56
|
At 17:29 17.05.2004, you wrote: > >>>>> On Sat, 15 May 2004 12:08:12 +0200, David Eriksson > <tw...@us...> said: > > > On Sat, 2004-05-15 at 00:09, Dennis Lubert wrote: > >> > >> I've tried to run a rather complex software with valgrind that > uses some > >> threads, and sends quite a lot of signals between those threads via > >> kill() as well as pthread_kill(), and sometimes even to itself. [...] > > > I think that the getpid() function returns the same PID for all threads > > when using valgrind. If you need to live with your complex > software, you > > probably also have to live without valgrind... > >But not necessarily without a "valgrind-like" tool. >You may wish to check out Chaperon, which doesn't "munge" on getpid(). >Chaperon is part of Insure++ (http://www.parasoft.com/insure). My main Problem isn't the getpid() thing, but, as the topic of the mail suggests, the signals SIGUSR1 that kill valgrind while running the program. Mainly, the program runs with same pids, but it "just" does not do what it should. But I could check some things within it, but my main problem was that it sends signals around, and even to itself, some with kill() some with pthread_kill() >Cheers, >-- >Paul Pluzhnikov pa...@pa... Carpe quod tibi datum est |
|
From: Rupert K. <rk...@mu...> - 2004-05-18 21:30:19
|
> > My main Problem isn't the getpid() thing, but, as the topic of the mail > suggests, the signals SIGUSR1 that kill valgrind while running the > program. Mainly, the program runs with same pids, but it "just" does not > do what it should. But I could check some things within it, but my main > problem was that it sends signals around, and even to itself, some with > kill() some with pthread_kill() > > Maybe this is unrelated, but I had similar problems when sending SIGUSR1 to a process with kill(1). As it turned out, the psutils version I was using was broken, and used different signal IDs than the kernel. Outch! You might want to check the exit status of your program with waitpid() and find out the actual signal number that was delivered. Rupert |