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
(3) |
2
(5) |
3
(7) |
4
(8) |
5
(3) |
|
6
(2) |
7
|
8
(2) |
9
(20) |
10
(2) |
11
(14) |
12
(21) |
|
13
(6) |
14
(9) |
15
(31) |
16
(7) |
17
(5) |
18
(14) |
19
(3) |
|
20
(6) |
21
(9) |
22
(19) |
23
(14) |
24
(16) |
25
(10) |
26
(3) |
|
27
(2) |
28
(1) |
29
(10) |
30
(6) |
31
(16) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 15:59:50
|
On Wed, 9 Mar 2005, Tom Truscott wrote: > I compiled valgrind-2.4.0.rc1 with an extra-picky gcc > and got some compiler warnings that perhaps should be fixed > (for a future release, no need to hold up 2.4). Nice catches, especially the memset() one. Which extra-picky gcc is this -- is it just a normal pre-4.0.0 snapshot? N |
|
From: Tom T. <tr...@un...> - 2005-03-09 15:46:42
|
I compiled valgrind-2.4.0.rc1 with an extra-picky gcc
and got some compiler warnings that perhaps should be fixed
(for a future release, no need to hold up 2.4).
coregrind/vg_scheduler.c 1066 warning: too few arguments for format
VG_(message)(Vg_DebugMsg,
"Thread %d supposed to be in LWP %d, but we're actually %d\n",
VG_(threads)[tid].os_state.lwpid, VG_(gettid)());
It looks like "Thread %d" needs a `tid' argument.
=======
coregrind/vg_signals.c 924 warning: suspicious sizeof(pointer_variable)
VG_(memset)(ehdr, 0, sizeof(ehdr));
It looks like sizeof(*ehdr) was intended, to clear the entire struct.
^
=======
coregrind/vg_main.c 185 warning: long unsigned int format, long long unsigned int arg (arg 5)
VG_(message)(Vg_DebugMsg,
" dispatch: %llu jumps (bb entries); of them %u (%lu%%) unchained.",
VG_(bbs_done),
VG_(unchained_jumps_done),
((ULong)(100) * (ULong)(VG_(unchained_jumps_done)))
/ ( VG_(bbs_done)==0 ? 1 : VG_(bbs_done) )
);
Changing %lu to %llu seems like the easiest fix.
=======
coregrind/vg_syscalls.c 6167 warning: long int format, long long int arg (arg 5)
coregrind/vg_syscalls.c 6167 warning: long unsigned int format, long long unsigned int arg (arg 6)
PRINT("SYSCALL[%d,%d](%3d) --> %ld (0x%lx)\n",
VG_(getpid)(), tid, syscallno, (Long)(Word)SYSRES, (ULong)SYSRES);
Changing %ld to %lld and %lx to %llx seems like the easiest fix.
=======
Thanks much for considering this,
Tom Truscott
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 15:04:25
|
On Wed, 9 Mar 2005, Christopher Travers wrote:
> I'm working on a project that recently building our executables with an
> indirect loader utility ("rtldi" http://www.bitwagon.com/rtldi/rtldi.html)
> instead of using ld-linux.so.2 directly. One of the unfortunate consequences
> of this is that valgrind no longer works with those executables (more
> specifically the program segfaults).
>
> I'm wondering if anyone has used valgrind with rtldi and if so, what sort of
> tweaking was required. The only interesting output I get is an invalid read,
> and the segfault. However, the same program works in valgrind without the
> rtldi loader, and runs fine with the rtldi loader outside of valgrind... any
> thoughts would be appreciated...
>
> ==31395== Invalid read of size 1
> ==31395== at 0x1B8E414B: (within /projects/images/bin/rtldi)
> ==31395== by 0x1B8E464F: (within /projects/images/bin/rtldi)
> ==31395== by 0x1B8E478B: (within /projects/images/bin/rtldi)
> ==31395== by 0x1B8E4C6C: (within /projects/images/bin/rtldi)
> ==31395== Address 0x114CC is not stack'd, malloc'd or (recently) free'd
I can't give you any specific advice about rtldi, but if you recompile it
with debugging info (-g) you'll get much more informative stack traces,
which may help identify the problem.
N
|
|
From: Christopher T. <ctr...@no...> - 2005-03-09 14:55:16
|
Hi all,
I'm working on a project that recently building our executables with an
indirect loader utility ("rtldi"
http://www.bitwagon.com/rtldi/rtldi.html) instead of using ld-linux.so.2
directly. One of the unfortunate consequences of this is that valgrind
no longer works with those executables (more specifically the program
segfaults).
I'm wondering if anyone has used valgrind with rtldi and if so, what
sort of tweaking was required. The only interesting output I get is an
invalid read, and the segfault. However, the same program works in
valgrind without the rtldi loader, and runs fine with the rtldi loader
outside of valgrind... any thoughts would be appreciated...
Thanks,
Chris
==31395==
==31395== Invalid read of size 1
==31395== at 0x1B8E414B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E464F: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E478B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E4C6C: (within /projects/images/bin/rtldi)
==31395== Address 0x114CC is not stack'd, malloc'd or (recently) free'd
==31395==
==31395== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==31395== Access not within mapped region at address 0x114CC
==31395== at 0x1B8E414B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E464F: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E478B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E4C6C: (within /projects/images/bin/rtldi)
==31395==
==31395== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==31395==
==31395== 1 errors in context 1 of 1:
==31395== Invalid read of size 1
==31395== at 0x1B8E414B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E464F: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E478B: (within /projects/images/bin/rtldi)
==31395== by 0x1B8E4C6C: (within /projects/images/bin/rtldi)
==31395== Address 0x114CC is not stack'd, malloc'd or (recently) free'd
==31395== IN SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==31395==
==31395== malloc/free: in use at exit: 0 bytes in 0 blocks.
==31395== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==31395==
==31395== No malloc'd blocks -- no leaks are possible.
--31395-- TT/TC: 0 tc sectors discarded.
--31395-- 51 tt_fast misses.
--31395-- translate: new 51 (607 -> 9095; ratio 149:10)
--31395-- discard 0 (0 -> 0; ratio 0:10).
--31395-- chainings: 20 chainings, 0 unchainings.
--31395-- dispatch: 308 jumps (bb entries); of them 51 (16%) unchained.
--31395-- 1/52 major/minor sched events.
--31395-- reg-alloc: 4 t-req-spill, 1654+14 orig+spill uis,
--31395-- 225 total-reg-rank
--31395-- sanity: 2 cheap, 1 expensive checks.
--31395-- ccalls: 160 C calls, 59% saves+restores avoided (564 bytes)
--31395-- 213 args, avg 0.84 setup instrs each (64 bytes)
--31395-- 0% clear the stack (480 bytes)
--31395-- 50 retvals, 18% of reg-reg movs avoided (18 bytes)
Segmentation fault
$
--
"Kant tells us always to treat human beings as an end
in themselves, and never as network addressable resources."
|
|
From: David J. <dj...@ho...> - 2005-03-09 14:43:13
|
During testing of 2.4rc1, I encountered a SIG11 that I can't explain. The program runs without problems without valgrind and shows no problems when run with valgrind 2.2. These tests were run on RH 9 I run valgrind like this /raid03/cs141/valgrind-2.4.0.rc1/bin/valgrind --tool=memcheck --num-callers=5 --db-attach=yes _ommain .... and get this ==25900== ==25900== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==25900== Bad permissions for mapped region at address 0xB1285EB0 ==25900== at 0x1EB29411: sgfitfl_ (sgfitfl.f:192) ==25900== by 0x203B09BC: tvsw1fc_ (pmtvsw.f:686) ==25900== by 0x203AB510: smtvswa_ (smtvsw.f:1276) ==25900== by 0x2019A4C0: analysis(ReaderMap const&, WriterMap const&, SfmContext const&, bool, bool) (LegacyAdaptor.cc:726) ==25900== by 0x201988F7: analysis(cReaderMap const&, WriterMap const&, SfmContext const&, bool, bool) (LegacySfmAdaptor.cc:372) ==25900== ==25900== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y ==25900== starting debugger with cmd: /usr/bin/gdb -nw /proc/26094/fd/1015 26094 GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... Attaching to program: /proc/26094/fd/1015, process 26094 ... after reading a lot of symbols (This is fortran, please bear with me) 0x1eb29411 in sgfitfl (x=(), y=(), n=4, dt=4, ncoeff=-1500, filt=(), midpt=0, ierr=0) at sgfitfl.f:192 192 DLT = DT / 1.0D3 check addresses of DLT and DT (gdb) p &dlt $1 = (PTR TO -> ( real*8 )) 0x1ee82310 Current language: auto; currently fortran (gdb) p &dt $2 = (PTR TO -> ( real*4 )) 0x2045361c dump instruction to see what's actually happening at 0x1EB29411 (gdb) x/20i &sgfitfl_ 0x1eb293d8 <sgfitfl>: push %ebp 0x1eb293d9 <sgfitfl+1>: mov %esp,%ebp 0x1eb293db <sgfitfl+3>: sub $0x90,%esp 0x1eb293e1 <sgfitfl+9>: mov %esi,0xfffffff0(%ebp) 0x1eb293e4 <sgfitfl+12>: mov %ebx,0xffffffc0(%ebp) 0x1eb293e7 <sgfitfl+15>: call 0x1eb293ec <sgfitfl+20> 0x1eb293ec <sgfitfl+20>: pop %ebx 0x1eb293ed <sgfitfl+21>: add $0x317614,%ebx 0x1eb293f3 <sgfitfl+27>: mov 0x24(%ebp),%eax 0x1eb293f6 <sgfitfl+30>: movl $0x0,(%eax) 0x1eb293fc <sgfitfl+36>: mov 0x14(%ebp),%eax 0x1eb293ff <sgfitfl+39>: flds (%eax) 0x1eb29401 <sgfitfl+41>: lea 0xfffed108(%ebx),%eax 0x1eb29407 <sgfitfl+47>: fldl (%eax) 0x1eb29409 <sgfitfl+49>: fdivrp %st,%st(1) 0x1eb2940b <sgfitfl+51>: lea 0x41910(%ebx),%eax 0x1eb29411 <sgfitfl+57>: fstpl (%eax) 0x1eb29413 <sgfitfl+59>: lea 0xfffed100(%ebx),%eax 0x1eb29419 <sgfitfl+65>: fldl (%eax) 0x1eb2941b <sgfitfl+67>: lea 0x41910(%ebx),%eax dump registers to see what's in %eax (gdb) info register eax 0x1eb293d8 515019736 ecx 0x0 0 edx 0x1b934800 462637056 ebx 0x1ee40a00 518261248 esp 0x1e36b2cc 0x1e36b2cc ebp 0x1e36b35c 0x1e36b35c esi 0x20451ff4 541401076 edi 0x3fe05 261637 eip 0x1eb29411 0x1eb29411 eflags 0x200216 2097686 cs 0x23 35 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0xf 15 gs 0x33 51 addresses appear to be ok. Nowhere do I see the address 0xB1285EB0 that valgrind complains about Any suggestion on what I should do to track down this problem? |
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 14:16:25
|
On Tue, 8 Mar 2005, Jeremy Fitzhardinge wrote: >> The way to fix this is to add another Bool arg -- >> "use_address_as_suggestion" or something -- to VG_(find_map_space)(). If >> it's true, we use the passed address as a suggestion (even if it's zero). >> If it's false, we put the block anywhere. > > Or use (Addr)-1. I prefer the extra Bool -- the code is clearer that way. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 14:13:39
|
On Wed, 9 Mar 2005, Dimitri Papadopoulos-Orfanos wrote: > You're using Valgrind 2.2.0, try the CVS version instead. Even easier, try 2.4.0 release candidate 1: http://www.goop.org/~jeremy/valgrind/dist> N |
|
From: Tom H. <to...@co...> - 2005-03-09 10:38:44
|
In message <200...@fr...>
Brad Hards <br...@fr...> wrote:
> On Wed, 9 Mar 2005 07:31 pm, Tom Hughes wrote:
>> > It won't configure on my PPC box (well, I am an optimist - must speak to
>> > Paulus).
>>
>> It doesn't have PPC support, so that isn't surprising. Or did you
>> mean it didn't work after you applied the PPC patch?
>
> I was hoping that PPC support might have been merged into the main tree. I
> didn't know if it would work or not. This is really just confirmation that
> the check for CPU types works - I haven't tried any patches.
No, the hope is to get PPC32 support into the 3.0 release later
in the year along with AMD64 support.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-09 10:28:42
|
Brad Hards wrote:
>It won't configure on my PPC box (well, I am an optimist - must speak to
>Paulus).
>
>
I should have mentioned that this release is still ia32 only...
>On a fairly up-to-date FC2 box, it configures and builds fine. make regtest
>fails three:
>== 199 tests, 1 stderr failure, 2 stdout failures =================
>memcheck/tests/zeropage (stdout)
>corecheck/tests/sigkill (stderr)
>none/tests/exec-sigmask (stdout)
>
>Result of running each of those is below. I don't know how much this helps, or
>what else I can do, so a bit of direction is probably required if more info
>is required.
>
>
Those are expected, unfortunately. They don't represent real bugs, but
the regression test suite is a bit brittle about differences between
different libc implementations. The zeropage is testing for something
we no longer enforce (though that may change back).
J
|
|
From: Brad H. <br...@fr...> - 2005-03-09 10:22:42
|
On Wed, 9 Mar 2005 07:31 pm, Tom Hughes wrote: > > It won't configure on my PPC box (well, I am an optimist - must speak to > > Paulus). > > It doesn't have PPC support, so that isn't surprising. Or did you > mean it didn't work after you applied the PPC patch? I was hoping that PPC support might have been merged into the main tree. I= =20 didn't know if it would work or not. This is really just confirmation that= =20 the check for CPU types works - I haven't tried any patches. Brad |
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-03-09 09:43:31
|
Hi, > I'm trying to use valgrind on a kylix "hello world" and it just says > "Segmentation fault" and exits. Any ideas? (it looks ok on "valgrind > --tool=none /bin/ls") You're using Valgrind 2.2.0, try the CVS version instead. Dimitri |
|
From: Tom H. <to...@co...> - 2005-03-09 08:32:01
|
In message <200...@fr...>
Brad Hards <br...@fr...> wrote:
> On Wed, 9 Mar 2005 06:44 am, Jeremy Fitzhardinge wrote:
>> I've made a test release of 2.4.0-rc1 and put it at
>> http://www.goop.org/~jeremy/valgrind/dist. I've included the source
>> tar, the source RPM and an FC3 i386 binary RPM.
> I downloaded the tarball and tried to build it.
>
> It won't configure on my PPC box (well, I am an optimist - must speak to
> Paulus).
It doesn't have PPC support, so that isn't surprising. Or did you
mean it didn't work after you applied the PPC patch?
> On a fairly up-to-date FC2 box, it configures and builds fine. make regtest
> fails three:
> == 199 tests, 1 stderr failure, 2 stdout failures =================
> memcheck/tests/zeropage (stdout)
> corecheck/tests/sigkill (stderr)
> none/tests/exec-sigmask (stdout)
>
> Result of running each of those is below. I don't know how much this helps, or
> what else I can do, so a bit of direction is probably required if more info
> is required.
None of those looks like a major problem - the zeropage one is already
being discussed and the other two are just caused by glibc details by
the looks of it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Brad H. <br...@fr...> - 2005-03-09 08:10:42
|
On Wed, 9 Mar 2005 06:44 am, Jeremy Fitzhardinge wrote: > I've made a test release of 2.4.0-rc1 and put it at > http://www.goop.org/~jeremy/valgrind/dist. I've included the source > tar, the source RPM and an FC3 i386 binary RPM. I downloaded the tarball and tried to build it. It won't configure on my PPC box (well, I am an optimist - must speak to=20 Paulus). On a fairly up-to-date FC2 box, it configures and builds fine. make regtest= =20 fails three: =3D=3D 199 tests, 1 stderr failure, 2 stdout failures =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D memcheck/tests/zeropage (stdout) corecheck/tests/sigkill (stderr) none/tests/exec-sigmask (stdout) Result of running each of those is below. I don't know how much this helps,= or=20 what else I can do, so a bit of direction is probably required if more info= =20 is required. Brad [bradh@banksia valgrind-2.4.0.rc1]$ ./memcheck/tests/zeropage succeeded?! succeeded?! succeeded?! [bradh@banksia valgrind-2.4.0.rc1]$ ./corecheck/tests/sigkill setting signal 1: Success getting signal 1: Success setting signal 2: Success getting signal 2: Success setting signal 3: Success getting signal 3: Success setting signal 4: Success getting signal 4: Success setting signal 5: Success getting signal 5: Success setting signal 6: Success getting signal 6: Success setting signal 7: Success getting signal 7: Success setting signal 8: Success getting signal 8: Success setting signal 9: Invalid argument getting signal 9: Success setting signal 10: Success getting signal 10: Success setting signal 11: Success getting signal 11: Success setting signal 12: Success getting signal 12: Success setting signal 13: Success getting signal 13: Success setting signal 14: Success getting signal 14: Success setting signal 15: Success getting signal 15: Success setting signal 16: Success getting signal 16: Success setting signal 17: Success getting signal 17: Success setting signal 18: Success getting signal 18: Success setting signal 19: Invalid argument getting signal 19: Success setting signal 20: Success getting signal 20: Success setting signal 21: Success getting signal 21: Success setting signal 22: Success getting signal 22: Success setting signal 23: Success getting signal 23: Success setting signal 24: Success getting signal 24: Success setting signal 25: Success getting signal 25: Success setting signal 26: Success getting signal 26: Success setting signal 27: Success getting signal 27: Success setting signal 28: Success getting signal 28: Success setting signal 29: Success getting signal 29: Success setting signal 30: Success getting signal 30: Success setting signal 31: Success getting signal 31: Success setting signal 32: Invalid argument getting signal 32: Invalid argument setting signal 33: Success getting signal 33: Success setting signal 34: Success getting signal 34: Success setting signal 35: Success getting signal 35: Success setting signal 36: Success getting signal 36: Success setting signal 37: Success getting signal 37: Success setting signal 38: Success getting signal 38: Success setting signal 39: Success getting signal 39: Success setting signal 40: Success getting signal 40: Success setting signal 41: Success getting signal 41: Success setting signal 42: Success getting signal 42: Success setting signal 43: Success getting signal 43: Success setting signal 44: Success getting signal 44: Success setting signal 45: Success getting signal 45: Success setting signal 46: Success getting signal 46: Success setting signal 47: Success getting signal 47: Success setting signal 48: Success getting signal 48: Success setting signal 49: Success getting signal 49: Success setting signal 50: Success getting signal 50: Success setting signal 51: Success getting signal 51: Success setting signal 52: Success getting signal 52: Success setting signal 53: Success getting signal 53: Success setting signal 54: Success getting signal 54: Success setting signal 55: Success getting signal 55: Success setting signal 56: Success getting signal 56: Success setting signal 57: Success getting signal 57: Success setting signal 58: Success getting signal 58: Success setting signal 59: Success getting signal 59: Success setting signal 60: Success getting signal 60: Success setting signal 61: Success getting signal 61: Success setting signal 62: Success getting signal 62: Success setting signal 65: Invalid argument getting signal 65: Invalid argument [bradh@banksia valgrind-2.4.0.rc1]$ ./none/tests/exec-sigmask full: signal 32 missing from mask |
|
From: Jeremy F. <je...@go...> - 2005-03-09 05:07:22
|
Nicholas Nethercote wrote:
> On Tue, 8 Mar 2005, Jeremy Fitzhardinge wrote:
> strace tells me the program (run natively) calls the syscall open()
> rather than creat(). Weird.
The creat() call was made obsolete by O_CREAT; if an architecture has a
creat() syscall, its only for ancient backwards compatibility.
> Neither of those are very appealing.
I had a better idea. We could:
* put back the ban on the lower 64k
* create a PROT_NONE mapping there
The mapping would appear in /proc/self/maps, and prevent a sub-Valgrind
from trying to put padding there. The only downside is the other
programs might get confused if they see the mapping there, and if they
hit a NULL pointer they'd get a SEGV_ACCERR rather than a SEGV_MAPERR
(which could be fixed up in the signal handler, because that's a piece
of code which really needs some more special cases).
> The former. I think the issue was that it gets very confusing if you
> pass 0x0 as the 'addr' parameter to VG_(find_map_space)() -- because
> it interprets that to mean "I don't care where you put it".
Yeah. mmap() uses smallish negative values to represent special pointer
values; that's why on x86-64, the 32-bit address space only goes up to
0xffff0000 (also the kernel internals represent the end of a mapping as
address-just-after, and having a mapping go from N-0 would be too
confusing).
> The way to fix this is to add another Bool arg --
> "use_address_as_suggestion" or something -- to VG_(find_map_space)().
> If it's true, we use the passed address as a suggestion (even if it's
> zero). If it's false, we put the block anywhere.
Or use (Addr)-1.
> In contrast, in languages like Haskell you have a "Maybe" type that
> looks like this:
>
> Maybe a = Just a | Nothing
Yep, it's one of my favorite things in CAML, along with pattern matching.
> No, but it's my standard trick for forcing a program to pause at a
> particular point -- usually to look at what /proc/self/maps looks like.
I generally use pause();
> I'm not sure. I'm very uneasy about changing native behaviour. I'm
> worried that in all the 250-odd syscalls there might be some cases
> that are like this but occur in less contrived code.
I'm not planning on worrying about it for 2.4.0 unless it breaks some
real code; we can reconsider it for 2.4.1+3.0.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 03:51:53
|
On Tue, 8 Mar 2005, Troels Walsted Hansen wrote: > I found a very minor issue... The copyright date says 2004. :-) The attached script fixes that. Jeremy, can you run it? Instructions are within. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 02:50:54
|
On Tue, 8 Mar 2005, Jeremy Fitzhardinge wrote:
>> ! at 0x........: creat (in /...libc...)
>> ! by 0x........: __libc_start_main (in /...libc...)
>> ! by 0x........: ...
>> --- 6,7 ----
>> ! at 0x........: open (in /...libc...)
>> ! by 0x........: main (fdleak_creat.c:18)
>>
>> ie. it looks like something has changed on my system so that libc's
>> creat() no calls open(). So probably not a problem.
>
> What's the context? I presume it ends up calling the same syscall? It
> doesn't look like anything more framepointer backtrace confusion.
strace tells me the program (run natively) calls the syscall open() rather
than creat(). Weird.
>> I'm not sure if this was a good thing to do -- IIRC I original put
>> that restriction in because some of the memory allocation functions
>> use 0 to represent failure, and so if a program did mmap(0x0, FIXED)
>> various problems could occur.
>
> Valgrind does a mmap(0, FIXED) as part of its address space padding; in
> general this is a legitimate but unusual operation. We could make it a
> clo which is off by default, but I'm not terribly keen on adding another
> special case clo. I guess a client request is another option (please
> let me mmap 0).
Neither of those are very appealing.
> What problems are you thinking of? Other problems occurring within
> Valgrind, or just that a program can get itself into a mess which we
> would detect too late?
The former. I think the issue was that it gets very confusing if you pass
0x0 as the 'addr' parameter to VG_(find_map_space)() -- because it
interprets that to mean "I don't care where you put it". Usually
VG_(find_map_space)() isn't called if you specify FIXED, but If you look
at the wrapper for mremap(), I think it will be an issue if you mremap()
some memory to address 0x0 with MREMAP_FIXED.
It's a type issue -- the problem comes from designating one particular
integer value as special, and then problems arise when you want to use
that value as a normal integer rather than the exceptional value.
VG_(find_map_space)() has inherited this problem from mmap() -- you can't
suggest to mmap(), without using MAP_FIXED, that you want the mapped
segment to go at 0x0.
The way to fix this is to add another Bool arg --
"use_address_as_suggestion" or something -- to VG_(find_map_space)(). If
it's true, we use the passed address as a suggestion (even if it's zero).
If it's false, we put the block anywhere.
Aside: malloc() suffers from a similar problem -- it can never put a heap
block at 0x0 because 0x0 means "no block allocated". Another consequence
of this idiom is that it's really easy to forget to check for the presence
of the exceptional value. That's why posix_memalign() returns a Bool, and
puts the address of the allocated block (if one was allocated) in the 2nd
argument pass-by-reference -- it doesn't steal the value, and it's much
harder to forget to check for failure. Unfortunately, NULL-as-failure is
so engrained in general C programmming that this problem will never go
away. In contrast, in languages like Haskell you have a "Maybe" type that
looks like this:
Maybe a = Just a | Nothing
where 'a' can be any type. The nice thing here is that you don't have to
steal one of your normal values to represent failure, and also it's
impossible to forget to check for the "Nothing" failure case.
>> Another problem... this program:
>>
>> int main(void)
>> {
>> read(0,0,1);
>> }
>>
>> behaves differently under Valgrind compared to native -- it doesn't
>> wait for user input.
>
> [...]
>
> Is this read(fd, 0, 1) example from a real program?
No, but it's my standard trick for forcing a program to pause at a
particular point -- usually to look at what /proc/self/maps looks like.
> Do you think this will cause a real problem? This case isn't
> particularly well defined, and I think older kernels would have failed
> it immediately. I don't like having variences from native behaviour,
> but I don't think this is too serious.
I'm not sure. I'm very uneasy about changing native behaviour. I'm
worried that in all the 250-odd syscalls there might be some cases that
are like this but occur in less contrived code.
N
|
|
From: Jeremy F. <je...@go...> - 2005-03-09 02:04:23
|
Nicholas Nethercote wrote:
> fdleak_creat is new. The diff is:
>
> ! at 0x........: creat (in /...libc...)
> ! by 0x........: __libc_start_main (in /...libc...)
> ! by 0x........: ...
> --- 6,7 ----
> ! at 0x........: open (in /...libc...)
> ! by 0x........: main (fdleak_creat.c:18)
>
> ie. it looks like something has changed on my system so that libc's
> creat() no calls open(). So probably not a problem.
What's the context? I presume it ends up calling the same syscall? It
doesn't look like anything more framepointer backtrace confusion.
> I'm not sure if this was a good thing to do -- IIRC I original put
> that restriction in because some of the memory allocation functions
> use 0 to represent failure, and so if a program did mmap(0x0, FIXED)
> various problems could occur.
Valgrind does a mmap(0, FIXED) as part of its address space padding; in
general this is a legitimate but unusual operation. We could make it a
clo which is off by default, but I'm not terribly keen on adding another
special case clo. I guess a client request is another option (please
let me mmap 0).
What problems are you thinking of? Other problems occurring within
Valgrind, or just that a program can get itself into a mess which we
would detect too late?
> Another problem... this program:
>
> int main(void)
> {
> read(0,0,1);
> }
>
> behaves differently under Valgrind compared to native -- it doesn't
> wait for user input.
>
> The problem also arises from January 15, when you changed almost every
> use of the PRE_MEM_WRITE macro to your new SYS_PRE_MEM_WRITE macro.
> Did you write these new macros to address a particular problem? I
> don't like like this macro, because it assumes that any unaddressable
> argument causes the syscall to fail, which is not necessarily the
> case. And I'm not keen on the obvious fix -- change sys_read to use
> PRE_MEM_WRITE -- because I imagine that this
> non-failure-on-unaddressable-memory behaviour is possible on any
> number of the syscalls.
The specific problem I was trying to solve is where Valgrind crashes
with a SIGSEGV if you pass bogus arguments to a syscall. This isn't so
much a problem for simple buffers like read(), but it is if the memory
points to a structure which Valgrind inspects.
In this case, the read will fail either way, but it blocks first when
run natively. I guess there is the possibility that someone will map
memory under it while it is blocked so that it won't end up failing.
Rather than setting EFAULT, the alternative is for SYS_PRE_MEM_* to
return some flag saying "bad memory" to prevent any further tests on
it. This would complicate things, since it means the PRE and POST
wrappers would need to be made aware of it if they touch syscall memory.
As it is, there are possible races where a thread will remove memory
under a syscall anyway, so touching memory in a POST() function isn't
strictly safe, even if it was present in the PRE().
Is this read(fd, 0, 1) example from a real program? Do you think this
will cause a real problem? This case isn't particularly well defined,
and I think older kernels would have failed it immediately. I don't
like having variences from native behaviour, but I don't think this is
too serious.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 01:01:06
|
On Tue, 8 Mar 2005, Jeremy Fitzhardinge wrote: > I've made a test release of 2.4.0-rc1 and put it at > http://www.goop.org/~jeremy/valgrind/dist. I've included the source > tar, the source RPM and an FC3 i386 binary RPM. > > This is identical to CVS HEAD except for the version number. > > Please try it out. If it looks good, I think we should ship it. My machine: Debian 3.0. Linux charco.cs.utexas.edu 2.4.29 #1 SMP Mon Jan 24 09:20:36 CST 2005 i686 unknown GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. ---- I'm getting the following regtest failures: == 198 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/zeropage (stdout) corecheck/tests/fdleak_creat (stderr) leak-tree, manuel2, pth_once, threadederrno and vgtest_ume I've been getting for a while, and I'm not very worried about them. fdleak_creat is new. The diff is: ! at 0x........: creat (in /...libc...) ! by 0x........: __libc_start_main (in /...libc...) ! by 0x........: ... --- 6,7 ---- ! at 0x........: open (in /...libc...) ! by 0x........: main (fdleak_creat.c:18) ie. it looks like something has changed on my system so that libc's creat() no calls open(). So probably not a problem. The zeropage one I've not seen before. Valgrind used to prevent clients from doing an mmap(FIXED) in the bottom 64KB of memory. Jeremy, you changed VG_(valid_client_addr)() on January 15 (rev 1.229) to disable this. The commit log said: Misc changes needed so that Valgrind can run itself. I'm not sure if this was a good thing to do -- IIRC I original put that restriction in because some of the memory allocation functions use 0 to represent failure, and so if a program did mmap(0x0, FIXED) various problems could occur. I don't know why this test has been succeeding since Jan 15, only to fail now. Another problem... this program: int main(void) { read(0,0,1); } behaves differently under Valgrind compared to native -- it doesn't wait for user input. The problem also arises from January 15, when you changed almost every use of the PRE_MEM_WRITE macro to your new SYS_PRE_MEM_WRITE macro. Did you write these new macros to address a particular problem? I don't like like this macro, because it assumes that any unaddressable argument causes the syscall to fail, which is not necessarily the case. And I'm not keen on the obvious fix -- change sys_read to use PRE_MEM_WRITE -- because I imagine that this non-failure-on-unaddressable-memory behaviour is possible on any number of the syscalls. N |
|
From: Klint G. <kg...@kg...> - 2005-03-09 00:22:07
|
I'm trying to use valgrind on a kylix "hello world" and it just says
"Segmentation fault" and exits. Any ideas? (it looks ok on "valgrind
--tool=none /bin/ls")
valgrind --tool=none ./hello
Segmentation fault
valgrind -v --tool=none ./hello
Segmentation fault
uname -a
Linux rumpole 2.4.20-31.9smp #1 SMP Tue Apr 13 17:40:10 EDT 2004 i686 i686 i386 GNU/Linux
valgrind --version
valgrind-2.2.0
cat hello.dpr
program hello;
begin
writeln('hello world');
end.
ldd hello
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40017000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
libdl.so.2 => /lib/libdl.so.2 (0x40078000)
libc.so.6 => /lib/libc.so.6 (0x4007c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(gdb) backtrace full
#0 0xb10a40f7 in ?? ()
No symbol table info available.
#1 0xb000ba13 in ?? ()
No symbol table info available.
#2 0xb000bd9a in ?? ()
No symbol table info available.
#3 0xb000be01 in ?? ()
No symbol table info available.
#4 0xb00234dc in ?? ()
No symbol table info available.
#5 0xb00257c1 in ?? ()
No symbol table info available.
#6 0xb103d704 in ?? ()
No symbol table info available.
strace valgrind --tool=none ./hello >a.a 2>&1
execve("/usr/local/bin/valgrind", ["valgrind", "--tool=none", "./hello"], [/* 51 vars */]) = 0
uname({sys="Linux", node="rumpole", ...}) = 0
fcntl64(0, F_GETFD) = 0
fcntl64(1, F_GETFD) = 0
fcntl64(2, F_GETFD) = 0
geteuid32() = 503
getuid32() = 503
getegid32() = 503
getgid32() = 503
brk(0) = 0x80cfb78
brk(0x80d0b78) = 0x80d0b78
brk(0x80d1000) = 0x80d1000
getrlimit(0x9, 0xbfffed04) = 0
setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
open("/usr/local/lib/valgrind/stage2", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1658766, ...}) = 0
geteuid32() = 503
getegid32() = 503
getgroups32(0x20, 0x80cb524) = 2
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\4\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\0\4\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) = 4
pread(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \f\0\000"..., 52, 0) = 52
pread(4, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0iJ\1\0iJ\1\0\5\0\0\0\0"..., 96, 52) = 96
mmap2(0xb0000000, 532480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb0000000
mmap2(0xb0082000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x82) = 0xb0082000
mmap2(0xb0083000, 1417216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb0083000
mmap2(0xb1000000, 87796, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb1000000
mmap2(0xb1000000, 86016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0xb1000000
mmap2(0xb1015000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x15) = 0xb1015000
close(4) = 0
close(3) = 0
getpid() = 8500
open("/tmp/.pad.8500.1", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 3
unlink("/tmp/.pad.8500.1") = 0
open("/proc/self/maps", O_RDONLY|O_LARGEFILE) = 4
read(4, "08048000-080ab000 r-xp 00000000 "..., 10240) = 558
close(4) = 0
mmap2(NULL, 134512640, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
mmap2(0x80d1000, 2817716224, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x80d1000
mmap2(0xb01dd000, 14823424, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb01dd000
open("/proc/self/exe", O_RDONLY|O_LARGEFILE) = 4
uname({sys="Linux", node="rumpole", ...}) = 0
set_tid_address(0) = 8500
brk(0) = 0x80d1000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/tls", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=28672, ...}) = 0
open("/bin/lib/tls/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/tls/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/tls/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/tls/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/tls/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/tls", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/bin/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/bin/lib", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/tls/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/tls/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/tls/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/tls/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/tls/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/tls", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/kylix3/bin", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
open("/usr/local/pgsql/lib/tls/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/tls/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/tls/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/tls/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/tls/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/tls", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/i686/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/i686/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/i686", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/mmx/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib/mmx", 0xbfffe5c0) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/local/pgsql/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=52448, ...}) = 0
old_mmap(NULL, 52448, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb1016000
close(5) = 0
open("/lib/libdl.so.2", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\30"..., 512) = 512
fstat64(5, {st_mode=S_IFREG|0755, st_size=15900, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1023000
old_mmap(NULL, 13176, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xb1024000
old_mmap(0xb1027000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0x2000) = 0xb1027000
close(5) = 0
open("tls/i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/kylix3/bin/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/pgsql/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360W\1"..., 512) = 512
fstat64(5, {st_mode=S_IFREG|0755, st_size=1539996, ...}) = 0
old_mmap(0x42000000, 1267276, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xb1028000
old_mmap(0xb1158000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0x130000) = 0xb1158000
old_mmap(0xb115b000, 9804, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb115b000
close(5) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb1023ac0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb1016000, 52448) = 0
getrlimit(RLIMIT_DATA, {rlim_cur=2147483647, rlim_max=2147483647}) = 0
setrlimit(RLIMIT_DATA, {rlim_cur=0, rlim_max=2147483647}) = 0
open("/home/klint/.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory)
brk(0) = 0x80d1000
brk(0x80d2000) = 0x80d1000
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb115e000
open("/usr/local/lib/valgrind/vgskin_none.so", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\270\7\0"..., 512) = 512
fstat64(5, {st_mode=S_IFREG|0755, st_size=21341, ...}) = 0
old_mmap(NULL, 6848, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xb1016000
old_mmap(0xb1017000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0xb1017000
close(5) = 0
mprotect(0xb1016000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xb1016000, 4096, PROT_READ|PROT_EXEC) = 0
access("/usr/local/lib/valgrind/vgpreload_none.so", R_OK) = -1 ENOENT (No such file or directory)
mmap2(0xaff00000, 1048576, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xaff00000
munmap(0, 2951741440) = 0
open("./hello", O_RDONLY) = 5
open("./hello", O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0775, st_size=29100, ...}) = 0
geteuid32() = 503
getegid32() = 503
getgroups32(0x20, 0xbfffdd50) = 2
pread(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\304\333"..., 4096, 0) = 4096
pread(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\304\333"..., 52, 0) = 52
pread(6, "\6\0\0\0004\0\0\0004\200\4\0104\200\4\10\240\0\0\0\240"..., 160, 52) = 160
pread(6, "/lib/ld-linux.so.2\0", 19, 212) = 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\0 \f\0\000"..., 52, 0) = 52
pread(7, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0iJ\1\0iJ\1\0\5\0\0\0\0"..., 96, 52) = 96
mmap2(0x8048000, 28672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 6, 0) = 0x8048000
mmap2(0x804f000, 1048576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x804f000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
+---------------------------------------+-----------------+
: Klint Gore : "Non rhyming :
: EMail : kg...@kg... : slang - the :
: Snail : A.B.R.I. : possibilities :
: Mail University of New England : are useless" :
: Armidale NSW 2351 Australia : L.J.J. :
: Fax : +61 2 6772 5376 : :
+---------------------------------------+-----------------+
|
|
From: Troels W. H. <tr...@th...> - 2005-03-08 21:12:49
|
Jeremy Fitzhardinge wrote: >I've made a test release of 2.4.0-rc1 and put it at >http://www.goop.org/~jeremy/valgrind/dist. I've included the source >tar, the source RPM and an FC3 i386 binary RPM. > >This is identical to CVS HEAD except for the version number. > >Please try it out. If it looks good, I think we should ship it. > > I found a very minor issue... The copyright date says 2004. :-) ==32548== Memcheck, a memory error detector for x86-linux. ==32548== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==32548== Using valgrind-2.4.0.rc1, a program supervision framework for x86-linux. ==32548== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. Looking forward to trying the new architecture it with some real programs. Troels |
|
From: Jeremy F. <je...@go...> - 2005-03-08 19:44:52
|
I've made a test release of 2.4.0-rc1 and put it at http://www.goop.org/~jeremy/valgrind/dist. I've included the source tar, the source RPM and an FC3 i386 binary RPM. This is identical to CVS HEAD except for the version number. Please try it out. If it looks good, I think we should ship it. J |
|
From: Jeroen N. W. <jn...@xs...> - 2005-03-06 13:58:38
|
> hi, > > sorry if this has been answered before ... > I look for a way to integrate valgrind into my unit-test suite. > The unit-tests are written using check (http://check.sf.net). The > project uses the autotools. > Thus 'make check' runns the binaries and scripts listed in the TESTS > variable of the Makefile.am. > > Now it would be nice to run the tests under valgrind, use the macros > from e.g. memcheck.h at the end of each test and make the test fail if > there are leaks. > The problem is that the program is started without valgrind. > FWIW, here is how I integrate valgrind into my unit-test suite. I leave `make check` as it is, but add a new target `make valgrind` which memchecks all programs in variable TESTS in file Makefile.am. 1. In file configure.in, create the option to use valgrind: AC_ARG_WITH([valgrind], AC_HELP_STRING([--with-valgrind], [where Valgrind is installed on your system (default is no)]), [ac_cv_use_valgrind=$withval], [ac_cv_use_valgrind=no])dnl VALGRIND=$ac_cv_use_valgrind AC_SUBST(VALGRIND)dnl AM_CONDITIONAL(HAVEVALGRIND, test x$VALGRIND != xno)dnl VALGRIND_CPPFLAGS= if test $ac_cv_use_valgrind != no; then AC_DEFINE(HAVE_VALGRIND, 1, [Define if valgrind is to be used.]) if test -f $ac_cv_use_valgrind/valgrind.h; then VALGRIND_CPPFLAGS=-I$ac_cv_use_valgrind elif test -f $ac_cv_use_valgrind/include/valgrind.h; then VALGRIND_CPPFLAGS=-I$ac_cv_use_valgrind/include elif test -f $ac_cv_use_valgrind/valgrind/valgrind.h; then VALGRIND_CPPFLAGS=-I$ac_cv_use_valgrind/valgrind elif test -f $ac_cv_use_valgrind/include/valgrind/valgrind.h; then VALGRIND_CPPFLAGS=-I$ac_cv_use_valgrind/include/valgrind elif test -f $ac_cv_use_valgrind/valgrind/include/valgrind.h; then VALGRIND_CPPFLAGS=-I$ac_cv_use_valgrind/valgrind/include fi fi AC_SUBST(VALGRIND_CPPFLAGS)dnl 2a. Add some genaral stuff for valgrind in file Makefile.am: AM_CPPFLAGS = @VALGRIND_CPPFLAGS@ # and -Wall -W -pedantic etc. 2b. And specific stuff for the valgrind target: if HAVEVALGRIND VALPREFIX = $(TESTS_ENVIRONMENT) GLIBCPP_FORCE_NEW= VALDEFAULT = @VALGRIND@/bin/valgrind VALOPTIONS = --tool=memcheck -q --show-reachable=yes --leak-check=yes --num-callers=20 VALCMD = $(VALPREFIX) $(VALDEFAULT) $(VALOPTIONS) valgrind: $(TESTS) for i in $^; do $(VALCMD) ./$$i; done endif 3. In file Makefile.am, I also have TESTS_ENVIRONMENT = ulimit -St20; to prevent endless loops in both `make check` and `make valgrind`. The semicolon at the end of this statement is required. 4. You can use the following script to invoke `make valgrind` if and only if it is present in file Makefile: #!/bin/bash # Target valgrind need not be present and need not succeed. if grep -qE "^valgrind: " Makefile; then make valgrind || true fi Regards, Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-06 06:38:36
|
On Sat, 5 Mar 2005, Stefan Kost wrote: > Thus I need a mechanism, that restarts the binary whne it not runs under > valgrind. Thats what the code snipped should do. I'll try this out next week. Ok. Valgrind has to run a program from the very start -- it cannot attach itself to an already running program -- so I guess you'll have to do something like what you suggest. Good luck. N |
|
From: Stefan K. <en...@ho...> - 2005-03-05 17:54:45
|
Hi Nicholas, Some more explanation ;) the tests are written using the testing framework. One test-binary contains test suites, that in turn contains tests cases and these finally contain the tests. What I need is to make the test binary to be run under valgrind. The invokation of the test-binary can't be changed, as this is generated by the automake from Makefile.am. It just starts the binaries and depending on the return value, record a pass or a fail for the test. Thus I need a mechanism, that restarts the binary whne it not runs under valgrind. Thats what the code snipped should do. I'll try this out next week. Stefan > On Fri, 4 Mar 2005, Stefan Kost wrote: > >> sorry if this has been answered before ... >> I look for a way to integrate valgrind into my unit-test suite. >> The unit-tests are written using check (http://check.sf.net). The >> project uses the autotools. >> Thus 'make check' runns the binaries and scripts listed in the TESTS >> variable of the Makefile.am. >> >> Now it would be nice to run the tests under valgrind, use the macros >> from e.g. memcheck.h at the end of each test and make the test fail if >> there are leaks. >> The problem is that the program is started without valgrind. > > > Which program -- the test framework, or the individual tests? > >> One hack to solve it would be something like >> >> if(!RUNNING_ON_VALGRIND) { >> char cmd[FILENAME_MAX]; >> >> sprintf(cmd,"valgrind %s %s",valgrind_opts,argv[0]); >> argv[0]=cmd; >> execv(cmd, argv); >> } >> >> I've not yet tried it. Anyone a better idea? Commants? > > > It's unclear where that code goes -- in the programs being tested? In > the test framework? I also don't really see how it works. > > I would think that you need to find some way within the test framework > to augment the command lines used to run the individual tests, and > prefix them with "valgrind ...". > > N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-05 01:24:04
|
On Fri, 4 Mar 2005, Fabio Margarido wrote: > Hi folks, I've been using valgrind for the last few weeks and it's > really helped me. I'm new to this mailing list and quicly browsed the > archives to find possible prior answers to my question, but couldn't > find any.. Sorry if I'm posting duplicate questions. > My problem is: I'm running Mandrake 10.1 on a 733 Mhz with 256 MB of > memory box, and valgrind ran smoothly without any problems. But > yesterday I had to upgrade my glibc from version 2.3.3 to 2.3.4, and > running valgrind produces the following error message since then: > > ==1174== Conditional jump or move depends on uninitialised value(s) > ==1174== at 0x1B8F455F: strchr (strchr.S:177) > > and often this other message as well: > > ==1247== Invalid free() / delete / delete[] > ==1247== at 0x1B904349: free (vg_replace_malloc.c:153) > ==1247== by 0x1BA2E1AB: (within /lib/tls/libc-2.3.4.so) > ==1247== by 0x1BA2DC51: __libc_freeres (in /lib/tls/libc-2.3.4.so) > ==1247== by 0x1B8FDC04: _vgw(float, long double,...)(...)(long > double,...)(short) (vg_intercept.c:117) > ==1247== Address 0x1B8FBD58 is not stack'd, malloc'd or (recently) free'd > > The same program ran smoothly when I had glibc2.3.3. Has anyone else > had that sort of problem or know the cause and how to fix it? Thanks a > lot. They're probably bugs in glibc. For the second one, try --run-libc-freeres=no, which might make it go away (but also might make --leak-check=yes report leaks in glibc that you aren't interested in). Or you could write a suppression for it. For the first, it's harder to say, but suppressing it might be the best thing. N |