You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(39) |
2
(29) |
3
(27) |
4
(50) |
5
(37) |
|
6
(14) |
7
(28) |
8
(44) |
9
(38) |
10
(32) |
11
(49) |
12
(51) |
|
13
(37) |
14
(32) |
15
(70) |
16
(50) |
17
(43) |
18
(56) |
19
(23) |
|
20
(22) |
21
(36) |
22
(12) |
23
(22) |
24
(10) |
25
(13) |
26
(21) |
|
27
(17) |
28
(16) |
29
(33) |
30
(14) |
|
|
|
|
From: Tom H. <to...@co...> - 2005-11-08 09:41:50
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> The problem is that the first mprotect has PROT_GROWSDOWN set and that
> causes mprotect to fail with EINVAL if the underlying VMA in the kernel
> doesn't have VM_GROWSDOWN set. The normal system provided stack does
> have that set, but our one doesn't and there is no way to set it from
> user space as far as I know.
>
> This isn't new in version 3 as far as I know - there are complaints
> about it with older versions I think.
>
> What PROT_GROWSDOWN does is to cause the kernel to round down the
> start address given to that of the underlying VMA and apply the
> protection specified to the whole area. In other words the stack
> extension area also gets those permissions.
The critical files to understand all this are mm/mprotect.c in the
kernel and sysdeps/unix/sysv/linux/dl-execstack.c in glibc.
The kernel provides PROT_GROWSDOWN and PROT_GROWSUP which round the
start/end address of mprotect to the start/end of the underlying vma
and glibc uses that as an easy way to change the protection of the
stack by calling mprotect on the last page of the stack with
PROT_GROWSDOWN set.
The sanity check provided by the kernel is that the vma must have
the VM_GROWSDOWN/VM_GROWSUP flag set as appropriate.
If that mprotect fails with EINVAL then glibc falls back to doing a
binary search to try and work out the size of the stack and change
it's protection. Obviously your glibc is not doing that for some
reason - I have glibc 2.3.5 if that helps.
> I believe that the valgrind address space manager copies the
> permissions of the area being extended when extending into a
> reservation so we can probably just clear PROT_GROWSUP/PROT_GROWSDOWN
> when we are processing an extendable area.
It's a bit more complicated than that - we need to check that we
are working on an area with an appropriate reservation next to
it - much like the kernel checks for VM_GROWSDOWN - and then move
the start address and length as appropriate and clear the flag.
The attached patch seems to work for me - if it works for you as
well then I guess we can go with it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-08 09:00:14
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> it seems valgrind 3.1 cannot deal anymore with executable stack requirement.
It seems to work find on my FC4 box with your test case.
> LD_LIBRARY_PATH=. valgrind --trace-syscalls=yes ./test
>
> gives:
>
> SYSCALL[671,1](125) sys_mprotect ( 0xBEE5C000, 4096, 16777223 )[sync] -->
> Failure(0x16)
> SYSCALL[671,1]( 6) sys_close ( 3 )[sync] --> Success(0x0)
> SYSCALL[671,1](146) sys_writev ( 2, 0xBEE5C3B8, 10 ) --> [async] ...
> ./test: error while loading shared libraries: libtest.so: cannot enable
> executable stack as shared object requires: Invalid argument
>
> Any idea what could be wrong? looks like the actual mprotect fails
> with a very weird way.
Well EINVAL just means there is no mapping at that address. As you
haven't posted the rest of the log we can't see if there was an early
map call that mapped that address.
Curiously I see the same failure on my box but then it carries on
instead of stopping:
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFF000, 4096, 16777223 )[sync] --> Failure(0x16)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFF8000, 32768, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFC000, 16384, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFE000, 8192, 7 )[sync] --> Success(0x0)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFC000, 8192, 7 )[sync] --> Failure(0xC)
SYSCALL[1462,1]( 10) sys_mprotect ( 0x7FEFFD000, 4096, 7 )[sync] --> Failure(0xC)
Actually those ENOMEM errors I am getting are far weirder... at least
they would be if you believed the mprotect manual page. Looking at the
kernel source it seems you sometimes get that if the mapping doesn't
exist though.
Actually it looks like you always get ENOMEM for that so the manual
page is complete nonsense.
The problem is that the first mprotect has PROT_GROWSDOWN set and that
causes mprotect to fail with EINVAL if the underlying VMA in the kernel
doesn't have VM_GROWSDOWN set. The normal system provided stack does
have that set, but our one doesn't and there is no way to set it from
user space as far as I know.
This isn't new in version 3 as far as I know - there are complaints
about it with older versions I think.
What PROT_GROWSDOWN does is to cause the kernel to round down the
start address given to that of the underlying VMA and apply the
protection specified to the whole area. In other words the stack
extension area also gets those permissions.
I believe that the valgrind address space manager copies the
permissions of the area being extended when extending into a
reservation so we can probably just clear PROT_GROWSUP/PROT_GROWSDOWN
when we are processing an extendable area.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2005-11-08 03:51:41
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-11-08 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 200 tests, 83 stderr failures, 3 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stderr) memcheck/tests/malloc_usable (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign2 (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/mmaptest (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/null_socket (stderr) memcheck/tests/oset_test (stderr) memcheck/tests/overlap (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pipe (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/with-space (stderr) memcheck/tests/writev (stderr) memcheck/tests/x86/fpeflags (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_fork (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/scalar_vfork (stderr) memcheck/tests/x86/tronical (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/seg_override (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 200 tests, 83 stderr failures, 4 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stderr) memcheck/tests/malloc_usable (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign2 (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/mmaptest (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/null_socket (stderr) memcheck/tests/oset_test (stderr) memcheck/tests/overlap (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pipe (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/with-space (stderr) memcheck/tests/writev (stderr) memcheck/tests/x86/fpeflags (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_fork (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/scalar_vfork (stderr) memcheck/tests/x86/tronical (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/seg_override (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Nov 8 03:40:13 2005 --- new.short Tue Nov 8 03:51:36 2005 *************** *** 10,12 **** ! == 200 tests, 83 stderr failures, 4 stdout failures ================= memcheck/tests/addressable (stderr) --- 10,12 ---- ! == 200 tests, 83 stderr failures, 3 stdout failures ================= memcheck/tests/addressable (stderr) *************** *** 40,42 **** memcheck/tests/leak-tree (stderr) - memcheck/tests/leakotron (stdout) memcheck/tests/malloc1 (stderr) --- 40,41 ---- |
|
From: <js...@ac...> - 2005-11-08 03:45:07
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-11-08 04:40:00 CET Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 167 tests, 18 stderr failures, 0 stdout failures ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) massif/tests/toobig-allocs (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/mremap (stderr) |
|
From: Tom H. <to...@co...> - 2005-11-08 03:41:33
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-11-08 03:30:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 201 tests, 6 stderr failures, 2 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/seg_override (stdout) |
|
From: Tom H. <th...@cy...> - 2005-11-08 03:23:23
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-11-08 03:15:04 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... failed
Last 20 lines of verbose log follow echo
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
error: while running 'automake -a'
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 200 tests, 16 stderr failures, 2 stdout failures =================
memcheck/tests/addressable (stderr)
memcheck/tests/describe-block (stderr)
memcheck/tests/erringfds (stderr)
memcheck/tests/leak-0 (stderr)
memcheck/tests/leak-cycle (stderr)
memcheck/tests/leak-regroot (stderr)
memcheck/tests/leak-tree (stderr)
memcheck/tests/match-overrun (stderr)
memcheck/tests/mempool (stderr)
memcheck/tests/nanoleak (stderr)
memcheck/tests/partiallydefinedeq (stderr)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/sigkill (stderr)
memcheck/tests/stack_changes (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
none/tests/x86/seg_override (stdout)
none/tests/x86/yield (stdout)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Tue Nov 8 03:21:44 2005
--- new.short Tue Nov 8 03:23:10 2005
***************
*** 2,28 ****
Checking out valgrind source tree ... done
! Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 200 tests, 16 stderr failures, 2 stdout failures =================
! memcheck/tests/addressable (stderr)
! memcheck/tests/describe-block (stderr)
! memcheck/tests/erringfds (stderr)
! memcheck/tests/leak-0 (stderr)
! memcheck/tests/leak-cycle (stderr)
! memcheck/tests/leak-regroot (stderr)
! memcheck/tests/leak-tree (stderr)
! memcheck/tests/match-overrun (stderr)
! memcheck/tests/mempool (stderr)
! memcheck/tests/nanoleak (stderr)
! memcheck/tests/partiallydefinedeq (stderr)
! memcheck/tests/pointer-trace (stderr)
! memcheck/tests/sigkill (stderr)
! memcheck/tests/stack_changes (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
! none/tests/x86/seg_override (stdout)
! none/tests/x86/yield (stdout)
--- 2,25 ----
Checking out valgrind source tree ... done
! Configuring valgrind ... failed
+ Last 20 lines of verbose log follow echo
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ error: while running 'automake -a'
|
|
From: Tom H. <th...@cy...> - 2005-11-08 03:22:08
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-11-08 03:10:09 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 177 tests, 1 stderr failure, 1 stdout failure ================= none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2005-11-08 03:20:56
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-11-08 03:10:09 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... failed
Last 20 lines of verbose log follow echo
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
Use of uninitialized value in hash element at /usr/bin/automake line 8459.
Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
: warning: automake does not support noinst_PROGRAMS being defined conditionally
error: while running 'automake -a'
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 200 tests, 4 stderr failures, 1 stdout failure =================
memcheck/tests/mempool (stderr)
memcheck/tests/pointer-trace (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
none/tests/x86/seg_override (stdout)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Tue Nov 8 03:19:26 2005
--- new.short Tue Nov 8 03:20:52 2005
***************
*** 2,15 ****
Checking out valgrind source tree ... done
! Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 200 tests, 4 stderr failures, 1 stdout failure =================
! memcheck/tests/mempool (stderr)
! memcheck/tests/pointer-trace (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
! none/tests/x86/seg_override (stdout)
--- 2,25 ----
Checking out valgrind source tree ... done
! Configuring valgrind ... failed
+ Last 20 lines of verbose log follow echo
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ Use of uninitialized value in hash element at /usr/bin/automake line 8459.
+ Use of uninitialized value in list assignment at /usr/bin/automake line 8448.
+ Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8449.
+ : warning: automake does not support noinst_PROGRAMS being defined conditionally
+ error: while running 'automake -a'
|
|
From: Tom H. <th...@cy...> - 2005-11-08 03:18:38
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-11-08 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 177 tests, 1 stderr failure, 1 stdout failure ================= none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2005-11-08 03:14:38
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-11-08 03:00:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 177 tests, 2 stderr failures, 0 stdout failures ================= none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) |
|
From: Scot M. <sco...@or...> - 2005-11-08 02:58:17
|
It is not that easy. ie, valgrind didn't fail. Instead, Oracle failed, because valgrind was too d*mn slow!!! ;-) I actually dont care whether you call it addrcheck, or "memcheck w/ an option to make it less heavy weight". They are obviously equivalent. Specifically, can memcheck be utilized in manner that gives us the more fatal errors (MLK/ABR/ABW/SBR/SBW/IPR/ZPR/NPR/COR/...), but doesn't check for the more mundane errors (mainly UMR and PLK). Definitions: ABR: Array bounds read: COR: Fatal core dump: IPR: Invalid pointer read: MSE: Memory segment error: NPR: Null pointer read: SBR: Stack array bounds read: SIG: Signal handled: UMR: Uninitialized memory read: ZPR: Zero page read: UMR: Uninitialized Memory Read PLK: Potential LeaK I will also try out the post 3.0.1 stuff you mentioned. Thanks, -sm Julian Seward wrote: >On Tuesday 08 November 2005 01:38, Scot McKinley wrote: > > >>Hi, sorry upfront if this has already been covered. >> >>I noticed the proposal about desupporting addrcheck. I would like to put >>out that addrcheck is still useful, and ask if there has been any work >>to get it supported in 3.0.1? >> >> >>Specifically, Oracle has a case where memcheck is unusable, whereas >>addrcheck is, due to its performance benefits (both cpu consumption and >>memory usage). >> >> > >Can you give some details of the problem: the platform you're running >on, what V says when it fails, and roughly what memory demands the >program has. > >Memory management, especially for large programs, has improved since >3.0.1, and you might have more luck trying the latest svn sources, >especially on a 64-bit machine, where we now support memchecking >programs which take up to about 14G natively. Try this: > > svn co svn://svn.valgrind.org/valgrind/trunk > cd trunk > ./autogen.sh > configure and build as usual > >I'd really like to get rid of addrcheck as I don't believe its hassle-to- >usefulness ratio justifies its continued existence, given that memcheck >provides a superset of the functionality. > >J > > |
|
From: Julian S. <js...@ac...> - 2005-11-08 02:43:02
|
> SYSCALL[671,1](125) sys_mprotect ( 0xBEE5C000, 4096, 16777223 )[sync] --> > Failure(0x16) > SYSCALL[671,1]( 6) sys_close ( 3 )[sync] --> Success(0x0) > SYSCALL[671,1](146) sys_writev ( 2, 0xBEE5C3B8, 10 ) --> [async] ... > ./test: error while loading shared libraries: libtest.so: cannot enable > executable stack as shared object requires: Invalid argument > > > Any idea what could be wrong? looks like the actual mprotect fails with a > very weird way. It could be that the mprotect was made to fail because the 16M area extended off the end of the stack into some place which V "owns". I'll look at it tomorrow. J |
|
From: Julian S. <js...@ac...> - 2005-11-08 02:37:11
|
On Tuesday 08 November 2005 01:38, Scot McKinley wrote: > Hi, sorry upfront if this has already been covered. > > I noticed the proposal about desupporting addrcheck. I would like to put > out that addrcheck is still useful, and ask if there has been any work > to get it supported in 3.0.1? > > > Specifically, Oracle has a case where memcheck is unusable, whereas > addrcheck is, due to its performance benefits (both cpu consumption and > memory usage). Can you give some details of the problem: the platform you're running on, what V says when it fails, and roughly what memory demands the program has. Memory management, especially for large programs, has improved since 3.0.1, and you might have more luck trying the latest svn sources, especially on a 64-bit machine, where we now support memchecking programs which take up to about 14G natively. Try this: svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh configure and build as usual I'd really like to get rid of addrcheck as I don't believe its hassle-to- usefulness ratio justifies its continued existence, given that memcheck provides a superset of the functionality. J |
|
From: Dirk M. <dm...@gm...> - 2005-11-08 02:26:38
|
Hi,
it seems valgrind 3.1 cannot deal anymore with executable stack requirement.
testcase:
=== libtest.c ===
void foo()
{
__asm__("\n"
".section .note.GNU-stack,\"x\",@progbits\n"
".previous\n"
);
}
=== libtest.c ===
=== test.c ===
#include <stdio.h>
extern void foo();
int main()
{
foo();
printf("hello world\n");
return 0;
}
=== test.c ===
gcc -shared -o libtest.so libtest.c
gcc -o test test.c -L. -ltest
LD_LIBRARY_PATH=. valgrind --trace-syscalls=yes ./test
gives:
SYSCALL[671,1](125) sys_mprotect ( 0xBEE5C000, 4096, 16777223 )[sync] -->
Failure(0x16)
SYSCALL[671,1]( 6) sys_close ( 3 )[sync] --> Success(0x0)
SYSCALL[671,1](146) sys_writev ( 2, 0xBEE5C3B8, 10 ) --> [async] ...
./test: error while loading shared libraries: libtest.so: cannot enable
executable stack as shared object requires: Invalid argument
Any idea what could be wrong? looks like the actual mprotect fails with a very
weird way.
Dirk
|
|
From: <sv...@va...> - 2005-11-08 02:25:41
|
Author: sewardj
Date: 2005-11-08 02:25:37 +0000 (Tue, 08 Nov 2005)
New Revision: 5035
Log:
memcheck: make --partial-loads-ok=3Dyes work again, but now make it
the non-default (it's a hack after all).
Modified:
trunk/memcheck/docs/mc-manual.xml
trunk/memcheck/mac_shared.c
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/docs/mc-manual.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/docs/mc-manual.xml 2005-11-08 01:24:23 UTC (rev 5034)
+++ trunk/memcheck/docs/mc-manual.xml 2005-11-08 02:25:37 UTC (rev 5035)
@@ -46,9 +46,6 @@
<computeroutput>memcpy()</computeroutput> and related
functions</para>
</listitem>
- <listitem>
- <para>Some misuses of the POSIX pthreads API</para>
- </listitem>
</itemizedlist>
=20
</sect1>
@@ -159,19 +156,25 @@
=20
<listitem id=3D"partial">
<para><computeroutput>--partial-loads-ok=3Dyes</computeroutput>
- [default]</para>
- <para><computeroutput>--partial-loads-ok=3Dno</computeroutput></para=
>
- <para>Controls how Memcheck handles word (4-byte) loads from
+ </para>
+ <para><computeroutput>--partial-loads-ok=3Dno</computeroutput>[defau=
lt]
+ </para>
+ <para>Controls how Memcheck handles word-sized, word-aligned loads f=
rom
addresses for which some bytes are addressible and others are
- not. When <computeroutput>yes</computeroutput> (the
- default), such loads do not elicit an address error.
+ not. When <computeroutput>yes</computeroutput>,
+ such loads do not elicit an address error.
Instead, the loaded V bytes corresponding to the illegal
- addresses indicate undefined, and those corresponding to
+ addresses indicate Undefined, and those corresponding to
legal addresses are loaded from shadow memory, as usual.</para>
- <para>When <computeroutput>no</computeroutput>, loads from
- partially invalid addresses are treated the same as loads
- from completely invalid addresses: an illegal-address error
+ <para>When <computeroutput>no</computeroutput>(the default),=20
+ loads from partially invalid addresses are treated the same as=20
+ loads from completely invalid addresses: an illegal-address error
is issued, and the resulting V bytes indicate valid data.</para>
+ <para>Note that code that behaves in this way is in violation of
+ the the ISO C/C++ standards, and should be considered broken.
+ If at all possible, such code should be fixed. This flag should
+ be used only as a last resort.
+ </para>
</listitem>
=20
<listitem id=3D"strlen">
Modified: trunk/memcheck/mac_shared.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mac_shared.c 2005-11-08 01:24:23 UTC (rev 5034)
+++ trunk/memcheck/mac_shared.c 2005-11-08 02:25:37 UTC (rev 5035)
@@ -58,7 +58,7 @@
/*--- Command line options ---*/
/*------------------------------------------------------------*/
=20
-Bool MAC_(clo_partial_loads_ok) =3D True;
+Bool MAC_(clo_partial_loads_ok) =3D False;
Int MAC_(clo_freelist_vol) =3D 5000000;
LeakCheckMode MAC_(clo_leak_check) =3D LC_Summary;
VgRes MAC_(clo_leak_resolution) =3D Vg_LowRes;
@@ -100,7 +100,7 @@
" --leak-check=3Dno|summary|full search for memory leaks at exit?=
[summary]\n"
" --leak-resolution=3Dlow|med|high how much bt merging in leak chec=
k [low]\n"
" --show-reachable=3Dno|yes show reachable blocks in leak ch=
eck? [no]\n"
-" --partial-loads-ok=3Dno|yes too hard to explain here; see ma=
nual [yes]\n"
+" --partial-loads-ok=3Dno|yes too hard to explain here; see ma=
nual [no]\n"
" --freelist-vol=3D<number> volume of freed blocks queue [50=
00000]\n"
" --workaround-gcc296-bugs=3Dno|yes self explanatory [no]\n"
);
Modified: trunk/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mc_main.c 2005-11-08 01:24:23 UTC (rev 5034)
+++ trunk/memcheck/mc_main.c 2005-11-08 02:25:37 UTC (rev 5035)
@@ -417,7 +417,7 @@
SizeT i =3D szB-1;
SizeT n_addrs_bad =3D 0;
Addr ai;
- Bool aok;
+ Bool aok, partial_load_exemption_applies;
UWord abit, vbyte;
=20
PROF_EVENT(30, "mc_LOADVn_slow");
@@ -436,7 +436,25 @@
i--;
}
=20
- if (n_addrs_bad > 0)
+ /* This is a hack which avoids producing errors for code which
+ insists in stepping along byte strings in aligned word-sized
+ chunks, and there is a partially defined word at the end. (eg,
+ optimised strlen). Such code is basically broken at least WRT
+ semantics of ANSI C, but sometimes users don't have the option
+ to fix it, and so this option is provided. Note it is now
+ defaulted to not-engaged.
+
+ A load from a partially-addressible place is allowed if:
+ - the command-line flag is set
+ - it's a word-sized, word-aligned load
+ - at least one of the addresses in the word *is* valid
+ */
+ partial_load_exemption_applies
+ =3D MAC_(clo_partial_loads_ok) && szB =3D=3D VG_WORDSIZE=20
+ && VG_IS_WORD_ALIGNED(a)=20
+ && n_addrs_bad < VG_WORDSIZE;
+
+ if (n_addrs_bad > 0 && !partial_load_exemption_applies)
MAC_(record_address_error)( VG_(get_running_tid)(), a, szB, False =
);
=20
return vw;
|
|
From: Scot M. <sco...@or...> - 2005-11-08 01:38:22
|
Hi, sorry upfront if this has already been covered. I noticed the proposal about desupporting addrcheck. I would like to put out that addrcheck is still useful, and ask if there has been any work to get it supported in 3.0.1? Specifically, Oracle has a case where memcheck is unusable, whereas addrcheck is, due to its performance benefits (both cpu consumption and memory usage). Or, are there options we can give to memcheck to reduce it's memory/cpu consumption to be comparable to addrcheck. Thanks in advance. Regards, -sm |
|
From: <sv...@va...> - 2005-11-08 01:24:30
|
Author: sewardj Date: 2005-11-08 01:24:23 +0000 (Tue, 08 Nov 2005) New Revision: 5034 Log: fwrite.stdout.exp seems to be not present and make dist doesn't like that= . Modified: trunk/memcheck/tests/Makefile.am Modified: trunk/memcheck/tests/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/memcheck/tests/Makefile.am 2005-11-08 00:45:47 UTC (rev 5033) +++ trunk/memcheck/tests/Makefile.am 2005-11-08 01:24:23 UTC (rev 5034) @@ -30,7 +30,7 @@ execve.stderr.exp execve.stderr.exp2 execve.vgtest \ execve2.stderr.exp execve2.stderr.exp2 execve2.vgtest \ fprw.stderr.exp fprw.vgtest \ - fwrite.stderr.exp fwrite.stderr.exp2 fwrite.stdout.exp fwrite.vgtest \ + fwrite.stderr.exp fwrite.stderr.exp2 fwrite.vgtest \ inits.stderr.exp inits.vgtest \ inline.stderr.exp inline.stdout.exp inline.vgtest \ leak-0.vgtest leak-0.stderr.exp \ |
|
From: Julian S. <js...@ac...> - 2005-11-08 00:50:30
|
Euh, ok. Try r5033. The idea of readlink("/proc/self/exe") is pretty
good, but there are systems on which /proc/self/exe is borked. So I
fell back to what is essentially your original plan.
J
On Sunday 06 November 2005 14:23, Jeroen N. Witmond wrote:
> >> Forgive my ignorance, but why do you need to check the segment's file
> >> name
> >> at all? Now that V is one static executable, the only file to have
> >> SkFileV
> >> should be the V executable anyway.
> >
> > That's true, but I don't want to hardwire that assumption in.
> >
> > Anyway, what I suggested doesn't work, because argv[0] can be a
> > relative pathname, whereas the names in the NSegments are always
> > absolute paths.
> >
> > I just committed the change Nick suggested (r5020) which should allow
> > reading from in-place builds too. However, since I don't know how to
> > run the system in-place (I never do so myself) I haven't test it - can
> > you try?
>
> This change does not work, because the name constructed by
> coregrind/launcher.c to execve the tool is a symbolic link, which is
> resolved to the real name before it appears in /proc/self/maps. This real
> name does not contain the string '.in_place/'.
>
> The attached patch is a hack that solves both the relative file name
> problem and the symbolic link problem, without assuming that Valgrind is a
> single static module. It works for me, it does not break the regression
> test; but it probably is not a real fix, because of violations of the
> modularization of Valgrind. It's beyond me to fix that. :-)
>
> Jeroen.
|
|
From: <sv...@va...> - 2005-11-08 00:45:55
|
Author: sewardj
Date: 2005-11-08 00:45:47 +0000 (Tue, 08 Nov 2005)
New Revision: 5033
Log:
Second try at getting rid of the is_self() hack used to decide when to
load debug info from the V executable.
Modified:
trunk/coregrind/m_debuginfo/symtab.c
trunk/coregrind/m_main.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/pub_core_debuginfo.h
Modified: trunk/coregrind/m_debuginfo/symtab.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_debuginfo/symtab.c 2005-11-07 18:06:10 UTC (rev 503=
2)
+++ trunk/coregrind/m_debuginfo/symtab.c 2005-11-08 00:45:47 UTC (rev 503=
3)
@@ -130,14 +130,6 @@
that third segment, which is wrong and causes crashes.
*/
=20
-/* Make a guess (doesn't have to be 100% correct) as to whether a path
- is that of the valgrind exe we're using. */
-static Bool is_self ( HChar* filename )
-{=20
- return VG_(strstr)( filename, "/lib/valgrind/" ) !=3D NULL
- || VG_(strstr)( filename, ".in_place/" ) !=3D NULL;
-}
-
static void nuke_syms_in_range ( Addr start, SizeT length )
{
/* Repeatedly scan the segInfo list, looking for segInfos in this
@@ -168,7 +160,14 @@
}
}
=20
-void VG_(di_notify_mmap)( Addr a )
+/* Notify the debuginfo system about a new mapping. This is the way
+ new debug information gets loaded. If allow_SkFileV is True, it
+ will try load debug info if the mapping at 'a' belongs to Valgrind;
+ whereas normally (False) it will not do that. This allows us to
+ carefully control when the thing will read symbols from the
+ Valgrind executable itself. */
+
+void VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV )
{
NSegment* seg;
HChar* filename;
@@ -183,13 +182,13 @@
=20
filename =3D VG_(arena_strdup)( VG_AR_SYMTAB, filename );
=20
- ok =3D (seg->kind =3D=3D SkFileC || (seg->kind =3D=3D SkFileV && is_s=
elf(filename)))
- && seg->offset =3D=3D 0
- && seg->fnIdx !=3D -1
- && seg->hasR
- && seg->hasX
- && !seg->hasW
- && is_elf_object_file( (const void*)seg->start );
+ ok =3D (seg->kind =3D=3D SkFileC || (seg->kind =3D=3D SkFileV && allo=
w_SkFileV))
+ && seg->offset =3D=3D 0
+ && seg->fnIdx !=3D -1
+ && seg->hasR
+ && seg->hasX
+ && !seg->hasW
+ && is_elf_object_file( (const void*)seg->start );
=20
if (!ok) {
VG_(arena_free)(VG_AR_SYMTAB, filename);
Modified: trunk/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_main.c 2005-11-07 18:06:10 UTC (rev 5032)
+++ trunk/coregrind/m_main.c 2005-11-08 00:45:47 UTC (rev 5033)
@@ -2321,9 +2321,11 @@
seg_starts =3D get_seg_starts( &n_seg_starts );
vg_assert(seg_starts && n_seg_starts > 0);
=20
- /* show them all to the debug info reader */
+ /* show them all to the debug info reader. allow_SkFileV has to
+ be True here so that we read info from the valgrind executable
+ itself. */
for (i =3D 0; i < n_seg_starts; i++)
- VG_(di_notify_mmap)( seg_starts[i] );
+ VG_(di_notify_mmap)( seg_starts[i], True/*allow_SkFileV*/ );
=20
VG_(free)( seg_starts );
}
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-11-07 18:06:10 UTC (=
rev 5032)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-11-08 00:45:47 UTC (=
rev 5033)
@@ -1854,7 +1854,7 @@
arg5, arg6=20
);
/* Load symbols? */
- VG_(di_notify_mmap)( (Addr)sres.val );
+ VG_(di_notify_mmap)( (Addr)sres.val, False/*allow_SkFileV*/ );
}
=20
/* Stay sane */
Modified: trunk/coregrind/pub_core_debuginfo.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_debuginfo.h 2005-11-07 18:06:10 UTC (rev 503=
2)
+++ trunk/coregrind/pub_core_debuginfo.h 2005-11-08 00:45:47 UTC (rev 503=
3)
@@ -41,8 +41,16 @@
=20
#include "pub_tool_debuginfo.h"
=20
-extern void VG_(di_notify_mmap)( Addr a );
+/* Notify the debuginfo system about a new mapping. This is the way
+ new debug information gets loaded. If allow_SkFileV is True, it
+ will try load debug info if the mapping at 'a' belongs to Valgrind;
+ whereas normally (False) it will not do that. This allows us to
+ carefully control when the thing will read symbols from the
+ Valgrind executable itself. */
+extern void VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV );
+
extern void VG_(di_notify_munmap)( Addr a, SizeT len );
+
extern void VG_(di_notify_mprotect)( Addr a, SizeT len, UInt prot );
=20
extern SegInfo *VG_(read_seg_symbols) ( Addr addr, SizeT len,
|