You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
|
4
(7) |
5
|
6
(1) |
7
(2) |
8
(6) |
9
|
|
10
(9) |
11
(4) |
12
(6) |
13
(12) |
14
(13) |
15
|
16
(7) |
|
17
|
18
(8) |
19
(2) |
20
(11) |
21
(6) |
22
(9) |
23
(1) |
|
24
(1) |
25
(1) |
26
(1) |
27
(20) |
28
(5) |
29
(2) |
30
(2) |
|
31
(3) |
|
|
|
|
|
|
|
From: Karl <kh...@tr...> - 2004-10-13 09:49:00
|
On 2004-10-13 11:10:16 +0200, Karl Hasselström wrote:
> On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
>
> > In message <20041012172514.GA11829@malin>
> > kha...@he... wrote:
> >
> > > I get the following error from valgrind:
> > >
> > > ==13322== Valgrind detected that your program requires
> > > ==13322== the following unimplemented functionality:
> > > ==13322== 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.
> > >
> > > Rerunning with -v shows that I am indeed not getting valgrind's
> > > libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to
> > > use the correct library?
> >
> > It should use it automatically. One thing that might cause a problem
> > is having an rpath set in your executable - what does "objdump -p"
> > say about your program?
>
> RPATH /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
>
> which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
> installed in /home/kha/local/lara.hq.vtech, which means that the
> full path to the library is
> /home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
I stripped those first two paths (/home/kha/local/lara.hq.vtech/lib
and /home/kha/local/generic/lib) from my LD_LIBRARY_PATH, LIBRARY_PATH
and LD_RUN_PATH, rebuilt everything, and got an RPATH of
/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib. For some unfathomable
reason, this caused the program to use /lib/i686/libpthread-0.10.so
instead of /lib/tls/libpthread-0.61.so, and valgrind worked. It still
doesn't use valgrind's libpthread.so, but apparently
/lib/i686/libpthread-0.10 is nice enough.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-13 09:46:52
|
In message <20041013091016.GA6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
>
>> It should use it automatically. One thing that might cause a problem
>> is having an rpath set in your executable - what does "objdump -p"
>> say about your program?
>
> RPATH
> /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
>
> which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
> installed in /home/kha/local/lara.hq.vtech, which means that the full
> path to the library is
> /home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
The RPATH is your problem - you have /lib in there so the libpthread
in /lib will be found via the RPATH before LD_LIBRARY_PATH is searched
which is what would locate the valgrind version.
The way things are supposed to work is that valgrind adds it's own
library directory to LD_LIBRARY_PATH before starting the client
program so that the valgrind pthread library is found. Unfortunately
because RPATH takes priority over LD_LIBRARY_PATH (see man ld.so for
the search rules) the system one is being found first.
It's highly unusual to add the system library directories to the
RPATH in that way - normally you just add any special directories that
your program needs and let the system do it's default stuff to find
the system libraries.
I would suggest that you either drop the system libraries from RPATH,
use RUNPATH instead of RPATH, or add the valgrind library directory to
the RPATH so that valgrind pthread library is found.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Karl <kh...@tr...> - 2004-10-13 09:11:33
|
On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
> In message <20041012172514.GA11829@malin>
> kha...@he... wrote:
>
> > I get the following error from valgrind:
> >
> > ==13322== Valgrind detected that your program requires
> > ==13322== the following unimplemented functionality:
> > ==13322== 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.
> >
> > Rerunning with -v shows that I am indeed not getting valgrind's
> > libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to
> > use the correct library?
>
> It should use it automatically. One thing that might cause a problem
> is having an rpath set in your executable - what does "objdump -p"
> say about your program?
RPATH /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
installed in /home/kha/local/lara.hq.vtech, which means that the full
path to the library is
/home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-12 18:05:22
|
In message <20041012172514.GA11829@malin>
kha...@he... wrote:
> I get the following error from valgrind:
>
> ==13322== Valgrind detected that your program requires
> ==13322== the following unimplemented functionality:
> ==13322== 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.
>
> Rerunning with -v shows that I am indeed not getting valgrind's
> libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to use
> the correct library?
It should use it automatically. One thing that might cause a problem
is having an rpath set in your executable - what does "objdump -p" say
about your program?
> I have installed valgrind in a nonstandard directory (with the
> --prefix configure switch); could this be the problem?
So long as you give the correct prefix when you configure and build
valgrind you should be fine. If you install somewhere other than where
you told valgrind at configure time then you will break things.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <kha...@he...> - 2004-10-12 17:38:51
|
In case it's relevant: this is on a Fedora Core 2 system, with kernel
2.6.6.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: <kha...@he...> - 2004-10-12 17:25:19
|
I get the following error from valgrind:
==13322== Valgrind detected that your program requires
==13322== the following unimplemented functionality:
==13322== 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.
Rerunning with -v shows that I am indeed not getting valgrind's
libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to use
the correct library?
I have installed valgrind in a nonstandard directory (with the
--prefix configure switch); could this be the problem?
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-10-12 09:01:10
|
>> If this indeed is a problem, the patch below can be used to fix it. > > Unfortunately that would break it on all my test systems ;-) > > The best fix is probably to add an alternate set of results. Either that or to add a custom filter to fixup the output. > I see. In that case, the two files attached should help. :-) as_mmap.stderr.exp2 belongs in directory corecheck/tests, zeropage.stderr.exp2 belongs in directory memcheck/tests. zeropage suffers from the same problem as_mmap does. Cheers, Jeroen. |
|
From: Nicholas N. <nj...@ca...> - 2004-10-12 08:52:50
|
On Mon, 11 Oct 2004, Jacob Bower wrote:
> The output of 'strace ./valgrind' is:
>
> execve("./valgrind", ["./valgrind"], [/* 84 vars */]) = 0
> [...]
> open("/tmp/.pad.6690.1", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 3
> unlink("/tmp/.pad.6690.1") = 0
> open("/proc/self/maps", O_RDONLY|O_LARGEFILE) = 7
> read(7, "00000000-00000000 r-xp 00000000 "..., 10240) = 593
> close(7) = 0
> mmap2(NULL, 2969567232, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
That final mmap2() call is asking for 2.9GB of memory to be mapped,
starting at address 0x0. That's clearly bogus, and is almost certainly
trashing lots of real memory. So the question is, why is Valgrind doing
this?
The read() call is interesting -- looks like the first line in
/proc/self/maps is
0000000-00000000 r-xp 00000000 ...
What does that mean? I wonder if this zero-sized segment is confusing
Valgrind, eg. causing some arithmetic overflow because it doesn't expect
zero-size segments. Can you show us the output of 'cat /proc/self/maps'?
To go further yourself, you could try inserting diagnostic fprintf() calls
in order to determine exactly which mmap2() call is failing -- I think the
problem is in coregrind/ume.c, in particular the function as_pad() or
foreach_map(). If you find the location, if you could also determine the
particular problem by looking judiciously at some variable values (eg. is
it an arithmetic overflow problem?) that would be a great help. Sorry to
have to ask you to do this but it's difficult to debug this ourselves.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-12 08:40:07
|
On Mon, 11 Oct 2004, Jeroen N. Witmond wrote: > Recently an error message was changed. This change was applied to > memcheck/tests/writev.stderr.exp, but not to > memcheck/tests/writev.stderr.exp2. The patch below will correct this > problem. Fixed, thanks. N |
|
From: Jacob B. <ja...@do...> - 2004-10-11 18:43:00
|
Hi,
I'm having trouble with Valgrind 2.2.0 segfaulting immeadiatly before
any obvious processing has taken place, and I'd really like to get this
extremely useful utility working.
The crux of my problem is:
$ ./valgrind
Segmentation Fault
$
The build and install went smoothly using the following commands:
./configure --prefix=<somepath>
make clean all install
The output of gcc -v is:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking
--enable-long-long --enable-__cxa_atexit
--enable-languages=c,c++,ada,f77,objc,java
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
As you can see, I am using a Mandrake 9.1 installation however the
installation has many modifications which are outside of my control
although these hopefuly shouldn't affect things like the libc or gcc
installation.
Uname tells me I am running Linux kernel version: 2.4.25-04dgr, although
this may also have been patched/modified outside of my control.
The output of 'strace ./valgrind' is:
execve("./valgrind", ["./valgrind"], [/* 84 vars */]) = 0
uname({sys="Linux", node="<blanked>", ...}) = 0
fcntl64(0, F_GETFD) = 0
fcntl64(1, F_GETFD) = 0
fcntl64(2, F_GETFD) = 0
geteuid32() = 566
getuid32() = 566
getegid32() = 1201
getgid32() = 1201
brk(0) = 0x80d9878
brk(0x80da878) = 0x80da878
brk(0x80db000) = 0x80db000
getrlimit(0x9, 0xba909604) = 0
setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
open("<somepath>/lib/valgrind/stage2", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1706650, ...}) = 0
geteuid32() = 566
getegid32() = 1201
getgroups32(0x20, 0x80ce97c) = 5
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0L\276\0"..., 4096, 0) = 4096
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0L\276\0"..., 52, 0) = 52
pread(3, "\6\0\0\0004\0\0\0004\0\0\2604\0\0\260\340\0\0\0\340\0\0"..., 224, 52) = 224
pread(3, "/lib/ld-linux.so.2\0", 19, 276) = 19
open("/lib/ld-linux.so.2", O_RDONLY|O_LARGEFILE) = 7
pread(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 52, 0) = 52
pread(7, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0I\27\1\0I\27\1\0\5\0\0"..., 96, 52) = 96
mmap2(0xb0000000, 544768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb0000000
mmap2(0xb0085000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x84) = 0xb0085000
mmap2(0xb0086000, 1417216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb0086000
mmap2(0xb1000000, 77300, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb1000000
mmap2(0xb1000000, 73728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0xb1000000
mmap2(0xb1012000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x11) = 0xb1012000
close(7) = 0
close(3) = 0
getpid() = 6690
open("/tmp/.pad.6690.1", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 3
unlink("/tmp/.pad.6690.1") = 0
open("/proc/self/maps", O_RDONLY|O_LARGEFILE) = 7
read(7, "00000000-00000000 r-xp 00000000 "..., 10240) = 593
close(7) = 0
mmap2(NULL, 2969567232, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
The output of ulimit -a is:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
Any hints on how to solve this problem would be great!
Thanks,
--
Jacob Bower <ja...@do...>
Department of Computing - http://www.doc.ic.ac.uk/
Imperial College - http://www.ic.ac.uk/
|
|
From: Tom H. <th...@cy...> - 2004-10-11 18:23:55
|
In message <228...@we...>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> There seems to be a problem in corecheck/tests/as_mmap.stderr.exp (CVS).
> It expects valgrind to report problems with syscall mmap2, but program
> as_mmap.c uses syscall mmap, which valgrind reports correctly.
The problem is that as_mmap.c uses the glibc mmap() function so
there is no way of knowing whether mmap or mmap2 will be used.
Depending on how it is built, and what arguments are used, glibc
sometimes uses the old mmap system call and sometimes used the new
mmap2 system call.
> If this indeed is a problem, the patch below can be used to fix it.
Unfortunately that would break it on all my test systems ;-)
The best fix is probably to add an alternate set of results. Either
that or to add a custom filter to fixup the output.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-10-11 18:15:39
|
Recently an error message was changed. This change was applied to
memcheck/tests/writev.stderr.exp, but not to
memcheck/tests/writev.stderr.exp2. The patch below will correct this
problem.
Cheers,
Jeroen.
Index: memcheck/tests/writev.stderr.exp2
===================================================================
RCS file: /home/kde/valgrind/memcheck/tests/writev.stderr.exp2,v
retrieving revision 1.1
diff -u -r1.1 writev.stderr.exp2
--- memcheck/tests/writev.stderr.exp2 9 Mar 2004 09:16:35 -0000 1.1
+++ memcheck/tests/writev.stderr.exp2 11 Oct 2004 18:07:35 -0000
@@ -3,19 +3,19 @@
Syscall param writev(vector[...]) contains uninitialised or unaddressable
byte(s)
at 0x........: (within /...libc...)
by 0x........: main (writev.c:56)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EFAULT as expected
Syscall param writev(vector) contains uninitialised or unaddressable byte(s)
at 0x........: (within /...libc...)
by 0x........: main (writev.c:68)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EINVAL as expected
Syscall param readv(vector) contains uninitialised or unaddressable byte(s)
at 0x........: readv (in /...libc...)
by 0x........: main (writev.c:76)
- Address 0x........ is not stack'd, malloc'd or free'd
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Received EINVAL as expected
ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
|
|
From: Jeroen N. W. <jn...@xs...> - 2004-10-11 17:42:04
|
There seems to be a problem in corecheck/tests/as_mmap.stderr.exp (CVS). It expects valgrind to report problems with syscall mmap2, but program as_mmap.c uses syscall mmap, which valgrind reports correctly. If this indeed is a problem, the patch below can be used to fix it. Cheers, Jeroen. Index: corecheck/tests/as_mmap.stderr.exp =================================================================== RCS file: /home/kde/valgrind/corecheck/tests/as_mmap.stderr.exp,v retrieving revision 1.1 diff -u -r1.1 as_mmap.stderr.exp --- corecheck/tests/as_mmap.stderr.exp 16 Dec 2003 02:14:00 -0000 1.1 +++ corecheck/tests/as_mmap.stderr.exp 11 Oct 2004 17:36:00 -0000 @@ -1,9 +1,9 @@ -Warning: client syscall mmap2 tried to modify addresses 0x0-0x10000 +Warning: client syscall mmap tried to modify addresses 0x0-0x10000 mmap @ 0x00000000: Cannot allocate memory -Warning: client syscall mmap2 tried to modify addresses 0xB0000000-0xB0010000 +Warning: client syscall mmap tried to modify addresses 0xB0000000-0xB0010000 mmap @ top: Cannot allocate memory -Warning: client syscall mmap2 tried to modify addresses 0xB8000000-0xB8010000 +Warning: client syscall mmap tried to modify addresses 0xB8000000-0xB8010000 mmap @ top+.5G: Cannot allocate memory ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) |
|
From: Nicholas N. <nj...@ca...> - 2004-10-10 17:37:04
|
On Sun, 10 Oct 2004, Igmar Palsenberg wrote: > I was confused by the manual page of brk(), since that indicates brk() > returning -1 is things fail. Looking at the kernel code, brk() failing > just returns the current data segment border. Yes, it's one of the times when the kernel syscall and the glibc wrapper diverge significantly in behaviour. The man page describes the glibc version. I think getcwd() is another such example. N |
|
From: Tom H. <th...@cy...> - 2004-10-10 17:30:19
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>
> > > The limit actually get's set, but is never raised. This triggers grsec,
> > > which rightfully complains that later allocations in the data segment
> > > exceed the existing limits.
> >
> > When you that it is never raised, what do you mean? It isn't supposed
> > to be raised in the valgrinded process - that is the whole point. It
> > should be restored on exec however. Is that what you are saying isn't
> > happening?
>
> I was confused by the manual page of brk(), since that indicates brk()
> returning -1 is things fail. Looking at the kernel code, brk() failing
> just returns the current data segment border.
I believe there are substantial differences between what the brk
system call does and what the brk() function in glibc does, so you
might want to look at glibc as well.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2004-10-10 17:17:34
|
> > The limit actually get's set, but is never raised. This triggers grsec, > > which rightfully complains that later allocations in the data segment > > exceed the existing limits. > > When you that it is never raised, what do you mean? It isn't supposed > to be raised in the valgrinded process - that is the whole point. It > should be restored on exec however. Is that what you are saying isn't > happening? I was confused by the manual page of brk(), since that indicates brk() returning -1 is things fail. Looking at the kernel code, brk() failing just returns the current data segment border. I'll simply patch grsec to make it shut up, since it's hardly of relevance on this devel machine. > Equally, which later alloctions in the data segment are you talking > about? The whole point is to prevent any allocations in the data > segment and force the use of mmap instead. Clear now. I'll fix up grsec in this case :) Igmar |
|
From: Igmar P. <mai...@jd...> - 2004-10-10 17:04:39
|
> I am aware of this, as it makes RedHat 7.2 systems very slow. I've > never really been able to get to the bottom of it though. The time > is all taken during startup - once things are up and running it seems > to be fine. > > The best I was able to work out was that it was something to do with > the memory mapping as strace indicated that mmap was about the only > thing being done during the delay. I observed the same. It's not a kernel issue however : a newer glibc version and the problem goes away. I'll see if I can dig into this myseld. > > I can see VG looping the CPU. To give an indication : > > > > real 1m44.480s > > user 1m31.300s > > sys 0m0.950s > > Interesting that it's all user time. I was thinking it was the kernel > taking a long time to do the mmap calls. I suspect it loops somewhere when parsing symbols. -v indicates that libs.so is the only problem, other libs seem fine. > > Ik locks up a long time at > > > > ==13832== Reading syms from /lib/libc-2.2.4.so (0xB1027000) > > <messages about redirection> > > ==13832== Reading syms from /lib/libc-2.2.4.so (0x1B915000) > > > > bit eventually does finish. I'll see if I can bump the libc version to > > 2.2.5 and see if that makes a difference. It this bug-file worthy material > > ? > > It's probably worth filing a bug to get it on the record. I'll file on. Igmar |
|
From: Tom H. <th...@cy...> - 2004-10-10 16:04:01
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> In coregrind/vg_main.c, around line 2790 :
>
> // Get the current process datasize rlimit, and set it to zero.
> // This prevents any internal uses of brk() from having any effect.
> // We remember the old value so we can restore it on exec, so that
> // child processes will have a reasonable brk value.
> VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> zero.rlim_max = VG_(client_rlimit_data).rlim_max;
> VG_(setrlimit)(VKI_RLIMIT_DATA, &zero);
>
> The limit actually get's set, but is never raised. This triggers grsec,
> which rightfully complains that later allocations in the data segment
> exceed the existing limits.
When you that it is never raised, what do you mean? It isn't supposed
to be raised in the valgrinded process - that is the whole point. It
should be restored on exec however. Is that what you are saying isn't
happening?
Equally, which later alloctions in the data segment are you talking
about? The whole point is to prevent any allocations in the data
segment and force the use of mmap instead.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-10-10 16:02:08
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> I was force to do some coding on an older system (glibc 2.2.4 based), and
> I noticed it takes considerably more time to run an app under valgrind
> then on a somewhat newer system.
I am aware of this, as it makes RedHat 7.2 systems very slow. I've
never really been able to get to the bottom of it though. The time
is all taken during startup - once things are up and running it seems
to be fine.
The best I was able to work out was that it was something to do with
the memory mapping as strace indicated that mmap was about the only
thing being done during the delay.
> I can see VG looping the CPU. To give an indication :
>
> real 1m44.480s
> user 1m31.300s
> sys 0m0.950s
Interesting that it's all user time. I was thinking it was the kernel
taking a long time to do the mmap calls.
> Ik locks up a long time at
>
> ==13832== Reading syms from /lib/libc-2.2.4.so (0xB1027000)
> <messages about redirection>
> ==13832== Reading syms from /lib/libc-2.2.4.so (0x1B915000)
>
> bit eventually does finish. I'll see if I can bump the libc version to
> 2.2.5 and see if that makes a difference. It this bug-file worthy material
> ?
It's probably worth filing a bug to get it on the record.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2004-10-10 15:24:14
|
> bit eventually does finish. I'll see if I can bump the libc version to > 2.2.5 and see if that makes a difference. That was like hitting the jackpot : Do I need to file a bug for this ? 1.9.x didn't do this. Regards, Igmar |
|
From: Igmar P. <mai...@jd...> - 2004-10-10 15:19:46
|
Hi, In coregrind/vg_main.c, around line 2790 : // Get the current process datasize rlimit, and set it to zero. // This prevents any internal uses of brk() from having any effect. // We remember the old value so we can restore it on exec, so that // child processes will have a reasonable brk value. VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data)); zero.rlim_max = VG_(client_rlimit_data).rlim_max; VG_(setrlimit)(VKI_RLIMIT_DATA, &zero); The limit actually get's set, but is never raised. This triggers grsec, which rightfully complains that later allocations in the data segment exceed the existing limits. This might be worth looking in to. Regards, Igmar |
|
From: Igmar P. <mai...@jd...> - 2004-10-10 15:14:39
|
Hi, I was force to do some coding on an older system (glibc 2.2.4 based), and I noticed it takes considerably more time to run an app under valgrind then on a somewhat newer system. I can see VG looping the CPU. To give an indication : real 1m44.480s user 1m31.300s sys 0m0.950s to run an app that only has 1 printf() in main(). Ik locks up a long time at ==13832== Reading syms from /lib/libc-2.2.4.so (0xB1027000) <messages about redirection> ==13832== Reading syms from /lib/libc-2.2.4.so (0x1B915000) bit eventually does finish. I'll see if I can bump the libc version to 2.2.5 and see if that makes a difference. It this bug-file worthy material ? regards, Igmar |
|
From: Chen, F. <FC...@em...> - 2004-10-08 17:39:28
|
Indeed! Thanks a lot for your help!
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Friday, October 08, 2004 12:34 PM
To: val...@li...
Subject: Re: [Valgrind-users] make error
In message
<2A9...@em...>
"Chen, Feng" <FC...@em...> wrote:
> I just downloaded valgrind-2.2.0, did a "./configure" fine. However,
> when doing "make", I got the following errors:
>=20
> make[2]: Entering directory
> `/home/hammer/dev/tmp/valgrind/valgrind-2.2.0/coregrind'
>=20
> gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer
> -mpreferred-stack-boundary=3D2 -g -DELFSZ=3D32 -o valgrind -static =
-g
> -Wl,-e,_ume_entry stage1.o ume.o ume_entry.o ume_go.o
>=20
> /usr/bin/ld: cannot find -lc
You haven't got the static C library installed. You probably
need the glibc-static-devel rpm.
Tom
--=20
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <th...@cy...> - 2004-10-08 16:34:01
|
In message <2A9...@em...>
"Chen, Feng" <FC...@em...> wrote:
> I just downloaded valgrind-2.2.0, did a "./configure" fine. However,
> when doing "make", I got the following errors:
>
> make[2]: Entering directory
> `/home/hammer/dev/tmp/valgrind/valgrind-2.2.0/coregrind'
>
> gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer
> -mpreferred-stack-boundary=2 -g -DELFSZ=32 -o valgrind -static -g
> -Wl,-e,_ume_entry stage1.o ume.o ume_entry.o ume_go.o
>
> /usr/bin/ld: cannot find -lc
You haven't got the static C library installed. You probably
need the glibc-static-devel rpm.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chen, F. <FC...@em...> - 2004-10-08 15:48:08
|
Hello, =20 I just downloaded valgrind-2.2.0, did a "./configure" fine. However, when doing "make", I got the following errors: =20 make[2]: Entering directory `/home/hammer/dev/tmp/valgrind/valgrind-2.2.0/coregrind' gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=3D2 -g -DELFSZ=3D32 -o valgrind -static -g -Wl,-e,_ume_entry stage1.o ume.o ume_entry.o ume_go.o /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status make[2]: *** [valgrind] Error 1 make[2]: Leaving directory `/home/hammer/dev/tmp/valgrind/valgrind-2.2.0/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/hammer/dev/tmp/valgrind/valgrind-2.2.0/coregrind' make: *** [all] Error 2 [ =20 Any ideas why did it happen? Thanks a lot for your help! =20 FC |