|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-14 14:19:58
|
Hi, I get these warnings on a Red Hat 9 machine: $ valgrind ls [...] ==14433== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==14433== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==14433== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==14433== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==14433== Estimated CPU clock rate is 1995 MHz ==14433== For more details, rerun with: -v ==14433== ==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. ==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. [...] What do they mean exactly? Should these warnings be ignored? Should the program be fixed? -- Dimitri |
|
From: Jeremy F. <je...@go...> - 2003-11-14 16:45:35
|
On Fri, 2003-11-14 at 06:22, Dimitri Papadopoulos-Orfanos wrote: > Hi, > > I get these warnings on a Red Hat 9 machine: > > $ valgrind ls > [...] > ==14433== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==14433== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==14433== Using valgrind-2.0.0, a program supervision framework for > x86-linux. > ==14433== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==14433== Estimated CPU clock rate is 1995 MHz > ==14433== For more details, rerun with: -v > ==14433== > ==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. > ==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. > [...] > > What do they mean exactly? > Should these warnings be ignored? > Should the program be fixed? They're almost not worth warning about. SIGKILL and SIGSTOP cannot be caught or handled in any way, so trying to set them to anything other than SIG_DFL with sigaction is an error - but a very minor one with no side-effects. This warning is common with code which does something like: for(sig = 1; sig < NSIG; sig++) sigaction(sig, &sa, NULL); So ignore it unless you're being pedantic. J |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-14 17:18:02
|
Hi, >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. >>[...] >> >>What do they mean exactly? >>Should these warnings be ignored? >>Should the program be fixed? > > > They're almost not worth warning about. SIGKILL and SIGSTOP cannot be > caught or handled in any way, so trying to set them to anything other > than SIG_DFL with sigaction is an error - but a very minor one with no > side-effects. This warning is common with code which does something > like: > > for(sig = 1; sig < NSIG; sig++) > sigaction(sig, &sa, NULL); > > So ignore it unless you're being pedantic. I understand now. Thanks for explaining this. Maybe the wording can be improved, so that "normal" programers can understand it. For example by changing from: attempt to set SIGKILL handler in __NR_sigaction. to: attempt to set a handler for SIGKILL signal. Also maybe this can be added to the FAQ. If even 'ls' emits such warnings, I guess many other programs will emit them too. -- Dimitri |
|
From: Avery P. <ape...@ni...> - 2003-11-15 17:57:52
|
On Fri, Nov 14, 2003 at 06:20:14PM +0100, Dimitri Papadopoulos-Orfanos wrote: > >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction. > >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction. > > >They're almost not worth warning about. SIGKILL and SIGSTOP cannot be > >caught or handled in any way, so trying to set them to anything other > >than SIG_DFL with sigaction is an error - but a very minor one with no > >side-effects. This warning is common with code which does something > >like: > > > > for(sig = 1; sig < NSIG; sig++) > > sigaction(sig, &sa, NULL); > > Maybe the wording can be improved, so that "normal" programers can > understand it. For example by changing from: > attempt to set SIGKILL handler in __NR_sigaction. > to: > attempt to set a handler for SIGKILL signal. > > Also maybe this can be added to the FAQ. If even 'ls' emits such > warnings, I guess many other programs will emit them too. How about: "warning: attempt to set SIGKILL handler never has an effect"? Also, for programs that set the sighandler in a loop - apparently include ls on some systems - I bet they're usually *disabling* a special handler, ie. 'sa' is NULL in the code fragment below. It would probably give fewer spurious warnings if we just didn't print a warning when sa==NULL. Have fun, Avery |
|
From: Nicholas N. <nj...@ca...> - 2003-11-17 10:38:26
|
On Sat, 15 Nov 2003, Avery Pennarun wrote:
> On Fri, Nov 14, 2003 at 06:20:14PM +0100, Dimitri Papadopoulos-Orfanos wrote:
>
> > >>==14433== Warning: attempt to set SIGKILL handler in __NR_sigaction.
> > >>==14433== Warning: attempt to set SIGSTOP handler in __NR_sigaction.
> >
> > Maybe the wording can be improved, so that "normal" programers can
> > understand it. For example by changing from:
> > attempt to set SIGKILL handler in __NR_sigaction.
> > to:
> > attempt to set a handler for SIGKILL signal.
> >
> > Also maybe this can be added to the FAQ. If even 'ls' emits such
> > warnings, I guess many other programs will emit them too.
>
> How about: "warning: attempt to set SIGKILL handler never has an effect"?
I just committed a change so it prints this:
Warning: ignored attempt to set SIGKILL handler in sigaction();
the SIGKILL signal is uncatchable
> Also, for programs that set the sighandler in a loop - apparently include ls
> on some systems - I bet they're usually *disabling* a special handler, ie.
> 'sa' is NULL in the code fragment below. It would probably give fewer
> spurious warnings if we just didn't print a warning when sa==NULL.
No. Valgrind doesn't print the warning when sa==NULL.
N
|
|
From: Avery P. <ape...@ni...> - 2003-11-17 17:56:01
|
On Mon, Nov 17, 2003 at 10:37:43AM +0000, Nicholas Nethercote wrote: > Warning: ignored attempt to set SIGKILL handler in sigaction(); > the SIGKILL signal is uncatchable > > > Also, for programs that set the sighandler in a loop - apparently > > include ls on some systems - I bet they're usually *disabling* a special > > handler, ie. 'sa' is NULL in the code fragment below. It would probably > > give fewer spurious warnings if we just didn't print a warning when > > sa==NULL. > > No. Valgrind doesn't print the warning when sa==NULL. In that case, I think the warning is valid, and there's no question about removing it - people should really only set signal handlers on signals they understand, not try to foolishly catch every single one as if they knew what to do when they got them. Have fun, Avery |
|
From: Attila <sa...@fr...> - 2003-11-19 15:31:00
|
Hi, Nicholas Nethercote <nj...@ca...> wrote: > > I just committed a change so it prints this: > > Warning: ignored attempt to set SIGKILL handler in sigaction(); > the SIGKILL signal is uncatchable > Thank you for doing so. Could you please also replace the "KLUDGED call to: ..." messages to something more straightforward? For example I'd like to know what I am doing wrong when I make a "kludged call" to phtread_cond_destroy (I link pthread dinamically). BR, Attila |
|
From: Tom H. <th...@cy...> - 2003-11-19 15:43:50
|
In message <fre...@fm...>
sa...@fr... wrote:
> Could you please also replace the "KLUDGED call to: ..."
> messages to something more straightforward?
> For example I'd like to know what I am doing wrong when I
> make a "kludged call" to phtread_cond_destroy (I link
> pthread dinamically).
You're not doing anything wrong. It's just that you're using a part
of the pthread interface that valgrind currently doesn't support very
well. The kludged message is telling you that although valgrind has
done something in response to that call, it may well not have been
the right thing and that you program might therefore misbehave as a
result.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Attila <sa...@fr...> - 2003-11-20 08:55:45
|
Tom Hughes <th...@cy...> wrote: > In message <fre...@fm...> > sa...@fr... wrote: > > > Could you please also replace the "KLUDGED call to: ..." > > messages to something more straightforward? > > For example I'd like to know what I am doing wrong when I > > make a "kludged call" to phtread_cond_destroy (I link > > pthread dinamically). > > You're not doing anything wrong. It's just that you're using a part > of the pthread interface that valgrind currently doesn't support very > well. The kludged message is telling you that although valgrind has > done something in response to that call, it may well not have been > the right thing and that you program might therefore misbehave as a > result. > > Tom Thanks. First I thought that somehow my call was kludged, you see... What about something like this: "Call to phtread_cond_destroy, for which the valgrind implementation is KLUDGED (not mature). Your program might misbehave as a result." Or you can formulate it ever more nicely, I am not a native English speaker. But I think it definitely worths to be put to the FAQ at least (if this message is too long). Otherwise big thanks to the developers for this superb software!!! Attila > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:33:28
|
On Thu, 20 Nov 2003, Attila wrote:
> "Call to phtread_cond_destroy, for which the valgrind
> implementation is KLUDGED (not mature). Your program might
> misbehave as a result."
>
> Or you can formulate it ever more nicely, I am not a native
> English speaker.
>
> But I think it definitely worths to be put to the FAQ at
> least (if this message is too long).
The current warning is bad, 'kludge' is obscure, and it has confused
several people. It should definitely be changed.
Preferably the replacement warning would fit on one line, which the one
above doesn't. The similar warning "warning: call to foo() IGNORED" is
short and easily understandable... are there any simple English words that
mean "kind of done, but not properly"? Maybe "faked"? "Bluffed"? Or
maybe it can't be explained clearly in one word.
Or maybe two lines isn't so bad, eg:
warning: Valgrind's version of foo() is incomplete;
your program may misbehave as a result
warning: Valgrind's version of foo() does nothing;
your program may misbehave as a result
Comments?
N
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-20 10:27:09
|
Hi,
> Or maybe two lines isn't so bad, eg:
>
> warning: Valgrind's version of foo() is incomplete;
> your program may misbehave as a result
For what it's worth, I like this one.
Or maybe:
warning: Valgrind currently does not implement foo();
your program may misbehave as a result
> warning: Valgrind's version of foo() does nothing;
> your program may misbehave as a result
--
Dimitri
|
|
From: Jeremy F. <je...@go...> - 2003-11-20 17:29:22
|
On Thu, 2003-11-20 at 01:32, Nicholas Nethercote wrote: > Preferably the replacement warning would fit on one line, which the one > above doesn't. The similar warning "warning: call to foo() IGNORED" is > short and easily understandable... are there any simple English words that > mean "kind of done, but not properly"? Maybe "faked"? "Bluffed"? Or > maybe it can't be explained clearly in one word. > > Or maybe two lines isn't so bad, eg: > > warning: Valgrind's version of foo() is incomplete; > your program may misbehave as a result > > warning: Valgrind's version of foo() does nothing; > your program may misbehave as a result > > Comments? Well, for many of the functions they don't have user-visible side-effects anyway, so we should just be silent about them. pthread_cond_destroy being a good example - there's nothing it need to do, so doing nothing is perfectly reasonable. We should only print a message if we're not doing something, and that something has some kind of client-visible effect. J |