|
From: Lee, T. <TL...@ft...> - 2004-01-12 21:46:05
|
Hi --
=20
Apologies in advance if this is a usage error on my part or as has been
documented as I am new to valgrind.
=20
I got the following error when running valgrind against when making the
'system' call:
=20
+ valgrind --leak-check=3Dyes -v --num-callers=3D20 --track-fds=3Dyes =
vtest
=3D=3D3526=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D3526=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D3526=3D=3D Using valgrind-2.1.0, a program supervision framework =
for
x86-linux.
=3D=3D3526=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D3526=3D=3D Command line
=3D=3D3526=3D=3D vtest
=3D=3D3526=3D=3D Startup, with flags:
=3D=3D3526=3D=3D
--suppressions=3D/dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrin=
d
/default.supp
=3D=3D3526=3D=3D --leak-check=3Dyes
=3D=3D3526=3D=3D -v
=3D=3D3526=3D=3D --num-callers=3D20
=3D=3D3526=3D=3D --track-fds=3Dyes
=3D=3D3526=3D=3D Reading syms from /home/fes620/test/vtest
=3D=3D3526=3D=3D Reading syms from /lib/ld-2.2.4.so
=3D=3D3526=3D=3D Reading syms from
/VIEWS/fes620_DEV630_linux.vws/.s/00027/800001753ffc701cvgskin_memcheck.
so
=3D=3D3526=3D=3D Reading syms from
/VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so
=3D=3D3526=3D=3D Reading syms from /lib/libc-2.2.4.so
=3D=3D3526=3D=3D object doesn't have a symbol table
=3D=3D3526=3D=3D object doesn't have any debug info
=3D=3D3526=3D=3D Reading suppressions file:
/dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrind/default.supp
=3D=3D3526=3D=3D Estimated CPU clock rate is 997 MHz
=3D=3D3526=3D=3D=20
Hello World
proxy 3534 for tid 1 exited status -1, res 0
got signal 17 in LWP 3526 (3526)
=20
valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
`vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
=3D=3D3526=3D=3D at 0x401749FE: (within
/VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
=20
sched status:
=20
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D =
0x0
=3D=3D3526=3D=3D at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
=3D=3D3526=3D=3D by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
=3D=3D3526=3D=3D by 0x80484B2: main (vtest.c:4)
=20
Here is a test program I wrote to produce the above error:
=20
int main ()
{
printf ("Hello World\n");
system ("ls >/tmp/junk");
}
Info related to valgrind environment and usage:
=20
valgrind command invokation: valgrind --leak-check=3Dyes -v
--num-callers=3D20 --track-fds=3Dyes vtest
valgrind version: valgrind-2.1.0
Linux distribution: Red Hat Advanced Server 2.1
Kernel version: 2.4.9-e.5
glibc version: gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
=20
Thanks,
Tim
=20
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any erroneous
transmission. If you receive this message in error, please immediately
destroy it and notify the sender. You must not, directly or indirectly,
use, disclose, distribute, or copy any part of this message if you are
not the intended recipient.
=20
|
|
From: Tom H. <th...@cy...> - 2004-01-12 22:15:55
|
In message <76C...@us...>
"Lee, Tim" <TL...@ft...> wrote:
> Hello World
> proxy 3534 for tid 1 exited status -1, res 0
> got signal 17 in LWP 3526 (3526)
>
> valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
> ==3526== at 0x401749FE: (within
> /VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==3526== at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
> ==3526== by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
> ==3526== by 0x80484B2: main (vtest.c:4)
>
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
This looks similar to bug 71053 which we haven't had a good test
case for until now.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-01-13 11:52:09
|
In message <76C...@us...>
Tim Lee <TL...@ft...> wrote:
> ==3526==
> Hello World
> proxy 3534 for tid 1 exited status -1, res 0
> got signal 17 in LWP 3526 (3526)
>
> valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
> ==3526== at 0x401749FE: (within
> /VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==3526== at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
> ==3526== by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
> ==3526== by 0x80484B2: main (vtest.c:4)
>
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
I've tried this example on my systems and so far I've been unable to
reproduce the symptoms. On RedHat 9 I can't get it to fail and on
RedHat 7.2 it does fail sometimes, but with a different assertion:
valgrind: vg_proxylwp.c:973 (proxy_wait): Assertion `*status == proxy->exitcode' failed.
==31647== at 0x40175546: (within /usr/lib/valgrind/valgrind.so)
==31647== by 0x40175545: assert_fail (vg_mylibc.c:1161)
==31647== by 0x401755A2: vgPlain_core_assert_fail (vg_mylibc.c:1172)
==31647== by 0x40179087: proxy_wait (vg_proxylwp.c:973)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==31647== at 0x402F871A: __execve (../sysdeps/unix/sysv/linux/execve.c:70)
==31647== by 0x4028C991: __libc_system (../sysdeps/posix/system.c:109)
==31647== by 0x80484F2: main (71053.c:7)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Patrick O. <Pat...@in...> - 2004-02-10 15:52:22
|
On Mon, 2004-01-12 at 22:45, Lee, Tim wrote:
[ assert ksigismember ]
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
For all that it's worth: I got the same error in my
own application and can reproduce it with this test
program.
valgrind version: valgrind-2.1.0
Linux distribution: Red Hat 7.3 (modified)
Kernel version: 2.4.9-xxx
glibc version: gcc version 2.96
I found that disabling the two asserts in
vg_async_signalhandler() allowed valgrind to
proceed, without any apparent problems so far.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-10 22:24:16
|
On Tue, 10 Feb 2004, Patrick Ohly wrote:
> [ assert ksigismember ]
> > Here is a test program I wrote to produce the above error:
> >
> > int main ()
> > {
> > printf ("Hello World\n");
> > system ("ls >/tmp/junk");
> > }
>
> For all that it's worth: I got the same error in my
> own application and can reproduce it with this test
> program.
>
> valgrind version: valgrind-2.1.0
> Linux distribution: Red Hat 7.3 (modified)
> Kernel version: 2.4.9-xxx
> glibc version: gcc version 2.96
Just to add to the confusion, I tried that program and get:
==31559== Valgrind detected that your program requires
==31559== the following unimplemented functionality:
==31559== clone(): not supported by Valgrind.
We do now support programs linked against
libpthread.so, though. Re-run with -v and ensure that
you are picking up Valgrind's implementation of libpthread.so.
valgrind: CVS HEAD.
kernel: 2.4.20-24.9
glibc: stable 2.3.2
gcc: 3.2.2
Current Valgrind 2.0.0 branch works ok.
Very strange -- a trivial system() is tripping Valgrind up on my machine,
yet this is the first I've seen of it on the current HEAD?
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-15 00:03:29
|
On Wed, 11 Feb 2004, Tom Hughes wrote: > OK. It isn't vfork as such, it's a custom fork that system uses... > > If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you > will see that it defines FORK() before including the generic version > of the system() code. That version of FORK() actually uses clone with > the CLONE_PARENT_SETTID flag to get the value of the child's PID in > a variable in the parent for cancellation. Right... so we should be able to handle this variant of clone()? N |
|
From: Tom H. <th...@cy...> - 2004-02-15 09:32:17
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 11 Feb 2004, Tom Hughes wrote:
>
> > OK. It isn't vfork as such, it's a custom fork that system uses...
> >
> > If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you
> > will see that it defines FORK() before including the generic version
> > of the system() code. That version of FORK() actually uses clone with
> > the CLONE_PARENT_SETTID flag to get the value of the child's PID in
> > a variable in the parent for cancellation.
>
> Right... so we should be able to handle this variant of clone()?
I don't see why it shouldn't work if you just add that to the list of
cases which we handle in PRE(clone).
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-02-11 00:02:09
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> Just to add to the confusion, I tried that program and get:
>
> ==31559== Valgrind detected that your program requires
> ==31559== the following unimplemented functionality:
> ==31559== clone(): not supported by Valgrind.
> We do now support programs linked against
> libpthread.so, though. Re-run with -v and ensure that
> you are picking up Valgrind's implementation of libpthread.so.
>
> valgrind: CVS HEAD.
> kernel: 2.4.20-24.9
> glibc: stable 2.3.2
> gcc: 3.2.2
>
> Current Valgrind 2.0.0 branch works ok.
>
> Very strange -- a trivial system() is tripping Valgrind up on my machine,
> yet this is the first I've seen of it on the current HEAD?
I wonder if system is implemented using vfork rather than fork?
The NPTL C library implements fork using clone, and as part of
the NPTL/TLS changes I made valgrind handle that, but it may be
that vfork is also being done using clone with slightly different
flags and valgrind isn't catching that.
Try stracing the test program without valgrind and see what
system calls the system() is doing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-11 00:11:42
Attachments:
strace
|
On Wed, 11 Feb 2004, Tom Hughes wrote:
> > Very strange -- a trivial system() is tripping Valgrind up on my machine,
> > yet this is the first I've seen of it on the current HEAD?
>
> I wonder if system is implemented using vfork rather than fork?
>
> The NPTL C library implements fork using clone, and as part of
> the NPTL/TLS changes I made valgrind handle that, but it may be
> that vfork is also being done using clone with slightly different
> flags and valgrind isn't catching that.
>
> Try stracing the test program without valgrind and see what
> system calls the system() is doing.
Full trace attached. The interesting bit is:
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|0x11, [7814], <ignored>) = 7814
wait4(7814, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 7814
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(0) = ?
Um, hmm.
N |
|
From: Tom H. <th...@cy...> - 2004-02-11 09:58:23
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 11 Feb 2004, Tom Hughes wrote:
>
>> I wonder if system is implemented using vfork rather than fork?
>>
>> The NPTL C library implements fork using clone, and as part of
>> the NPTL/TLS changes I made valgrind handle that, but it may be
>> that vfork is also being done using clone with slightly different
>> flags and valgrind isn't catching that.
>>
>> Try stracing the test program without valgrind and see what
>> system calls the system() is doing.
>
> Full trace attached. The interesting bit is:
OK. It isn't vfork as such, it's a custom fork that system uses...
If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you
will see that it defines FORK() before including the generic version
of the system() code. That version of FORK() actually uses clone with
the CLONE_PARENT_SETTID flag to get the value of the child's PID in
a variable in the parent for cancellation.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-15 16:18:27
|
On Wed, 11 Feb 2004, Tom Hughes wrote: > If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you > will see that it defines FORK() before including the generic version > of the system() code. That version of FORK() actually uses clone with > the CLONE_PARENT_SETTID flag to get the value of the child's PID in > a variable in the parent for cancellation. Done, thanks. N |