|
From: Shevde, R. S \(GE Healthcare\) <Rak...@ge...> - 2006-10-10 11:21:31
|
I am running=20
$ valgrind --version
valgrind-3.2.1=20
$ nm -a memcheck | grep setprio
000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
What happens if the syscall is not implemented say for setpriority
The caller (in my case the exec I am testing) would get a return value
as success or failure..
I am wondering if that is the cause for failure later with SIGSEGV.
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, October 10, 2006 4:42 PM
To: val...@li...
Subject: Re: [Valgrind-users] Problem with REDIR
In message
<520C5E108EFD11468EB43142EFEAD1BD4E4333@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> It then complains about
> --2983-- WARNING: unhandled syscall: 141
> =3D=3D2983=3D=3D at 0x124B8657: setpriority (in =
/lib64/libc-2.3.6.so)
You haven't said what version of valgrind you are using, but this system
call is implemented in 3.2.1 so it obviously isn't the latest.
> setpriority is present in the coregrind syscall implementations.
Correct, and is hooked up on amd64-linux, so if you are getting that
error you are not running the current code.
> Please let me know on why do we get these REDIR (???) messages.
Those are normal, don't worry about them.
tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Shevde, R. S \(GE Healthcare\) <Rak...@ge...> - 2006-10-10 11:34:56
|
=20
One other thing I found out is=20
The exec of interest is loading a different set of vgp*.so
--2983-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
--2983-- Reading syms from /usr/sbin/dpserver (0x400000)
--2983-- Reading syms from /lib64/ld-2.3.6.so (0x11900000)
--2983-- Reading suppressions file: /usr/lib64/valgrind/default.supp
=3D=3D2983=3D=3D
--2983-- Reading syms from /usr/lib64/valgrind/vg_preload_core.so
(0x11A1C000)
--2983-- object doesn't have a symbol table
--2983-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck.so
(0x11B1E000)
--2983-- object doesn't have a symbol table
And I wrote a small test prog using setpriority() which is loading a
different vgp*.so files=20
--10565-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
--10565-- Arch and hwcaps: AMD64, amd64-sse2
--10565-- Valgrind library directory: /usr/local/lib/valgrind
--10565-- Reading syms from /home/sdc/rakesh/a.out (0x400000)
--10565-- Reading syms from /usr/local/lib/valgrind/amd64-linux/memcheck
(0x38000000)
--10565-- object doesn't have a dynamic symbol table
--10565-- Reading syms from /lib64/ld-2.3.6.so (0x3C1EB00000)
--10565-- Reading suppressions file:
/usr/local/lib/valgrind/default.supp
--10565-- Reading syms from
/usr/local/lib/valgrind/amd64-linux/vgpreload_core.so (0x4802000)
--10565-- Reading syms from
/usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4903000)
Would that give some clue, on this issue.
-----Original Message-----
From: Shevde, Rakesh S (GE Healthcare)=20
Sent: Tuesday, October 10, 2006 4:51 PM
To: 'Tom Hughes'; val...@li...
Subject: RE: [Valgrind-users] Problem with REDIR
I am running
$ valgrind --version
valgrind-3.2.1=20
$ nm -a memcheck | grep setprio
000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
What happens if the syscall is not implemented say for setpriority The
caller (in my case the exec I am testing) would get a return value as
success or failure..
I am wondering if that is the cause for failure later with SIGSEGV.
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Tuesday, October 10, 2006 4:42 PM
To: val...@li...
Subject: Re: [Valgrind-users] Problem with REDIR
In message
<520C5E108EFD11468EB43142EFEAD1BD4E4333@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> It then complains about
> --2983-- WARNING: unhandled syscall: 141
> =3D=3D2983=3D=3D at 0x124B8657: setpriority (in =
/lib64/libc-2.3.6.so)
You haven't said what version of valgrind you are using, but this system
call is implemented in 3.2.1 so it obviously isn't the latest.
> setpriority is present in the coregrind syscall implementations.
Correct, and is hooked up on amd64-linux, so if you are getting that
error you are not running the current code.
> Please let me know on why do we get these REDIR (???) messages.
Those are normal, don't worry about them.
tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2006-10-10 11:55:07
|
In message <520C5E108EFD11468EB43142EFEAD1BD4BF72A@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
>
> One other thing I found out is
> The exec of interest is loading a different set of vgp*.so
> --2983-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
> 20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
> --2983-- Reading syms from /usr/sbin/dpserver (0x400000)
> --2983-- Reading syms from /lib64/ld-2.3.6.so (0x11900000)
> --2983-- Reading suppressions file: /usr/lib64/valgrind/default.supp
> ==2983==
> --2983-- Reading syms from /usr/lib64/valgrind/vg_preload_core.so
> (0x11A1C000)
> --2983-- object doesn't have a symbol table
> --2983-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck.so
> (0x11B1E000)
> --2983-- object doesn't have a symbol table
>
> And I wrote a small test prog using setpriority() which is loading a
> different vgp*.so files
> --10565-- Linux version 2.6.15-2.4 (root@alfred) (gcc version 4.0.2
> 20051125 (Red Hat 4.0.2-8)) #1 SMP Fri May 26 09:51:20 CDT 2006
> --10565-- Arch and hwcaps: AMD64, amd64-sse2
> --10565-- Valgrind library directory: /usr/local/lib/valgrind
> --10565-- Reading syms from /home/sdc/rakesh/a.out (0x400000)
> --10565-- Reading syms from /usr/local/lib/valgrind/amd64-linux/memcheck
> (0x38000000)
> --10565-- object doesn't have a dynamic symbol table
> --10565-- Reading syms from /lib64/ld-2.3.6.so (0x3C1EB00000)
> --10565-- Reading suppressions file:
> /usr/local/lib/valgrind/default.supp
> --10565-- Reading syms from
> /usr/local/lib/valgrind/amd64-linux/vgpreload_core.so (0x4802000)
> --10565-- Reading syms from
> /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4903000)
>
> Would that give some clue, on this issue.
Yes - you have two copies of valgrind installed, one in /usr and one
in /usr/local and you have picked up different versions on different
runs, presumably due to a different path.
The one in /usr/local is newer that the one in /usr.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-10-10 11:40:38
|
In message <520C5E108EFD11468EB43142EFEAD1BD4E4334@BANMLVEM02.e2k.ad.ge.com>
Rakesh S. Shevde <Rak...@ge...> wrote:
> I am running
> $ valgrind --version
> valgrind-3.2.1
>
> $ nm -a memcheck | grep setprio
> 000000003803eca6 T vgSysWrap_generic_sys_setpriority_before
If you are getting that message then that is not the version you are
running - double check your path and make sure that you are running
the version that you think you are running.
Running with -d should also show you the path of the tool binary that
it is using.
There is no way that 3.2.1 should report the system call as unhandled
on amd64-linux as it is definitely hooked up to a handler.
> What happens if the syscall is not implemented say for setpriority
> The caller (in my case the exec I am testing) would get a return value
> as success or failure..
It would get an ENOSYS error.
> I am wondering if that is the cause for failure later with SIGSEGV.
I would think it unlikely, but as you haven't provided any details of
the SEGV it is hard to comment.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|