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
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Rich C. <Ric...@me...> - 2005-03-09 22:10:09
|
On Sun, 27 Feb 2005 13:59:10 -0600 (CST) Nicholas Nethercote <nj...@cs...> wrote: > On Fri, 25 Feb 2005, Julian Seward wrote: > > >> And should we consider defaulting to memcheck again? > > > > Personally I would like that. I find it annoying to constantly > > have to type --tool=memcheck (but not _always_, so .valgrindrc > > isn't the answer). > > .valgrindrc works with that. I'm in the same situation, so I have > --tool=memcheck in my .valgrindrc, and if I want to run something else I > just put that on the command line; command line-specified options take > precedence over the .valgrindrc ones so it all just works. > .valgrindrc works great when you are running code as your self on your own box. When you are working on a target in a production type environment, there is no .valgrindrc. I'd vote for the default of --tool=memcheck. -- Rich Coe ric...@me... General Electric Healthcare Technologies Global Software Platfroms, Computer Technology Team |
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 17:46:59
|
On Wed, 9 Mar 2005, Jeremy Fitzhardinge wrote: > It looks like the crash happened when massif is assembling its final report. > It seems that one of the pointers in the line > > xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space > > is equal to 0xe4e4e4e4 - a very clearly bogus pointer. > > (The "stack overflow" message is meaningless in this context; it failed to > grow the stack to that address, so it decided that it was an overflow.) > > Nick? I'll look at it tonight. N |
|
From: Jeremy F. <je...@go...> - 2005-03-09 17:09:35
|
James Begley wrote:
>== 200 tests, 2 stderr failures, 0 stdout failures =================
>memcheck/tests/scalar (stderr)
>memcheck/tests/scalar_supp (stderr)
>
>
These are expected. FC3's libc/gcc doesn't generate quite as long a
stack trace as is expected by the test.
>However, when I use the new version of massif, I get the following:
>
>====================================================================
>==19751==
>==19751== Stack overflow in thread 0: can't grow stack to 0xE4E4E4F4
>--19751-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
>exiting
>--19751-- si_code=1 Fault EIP: 0xB7D74051; Faulting address: 0xE4E4E4F4
>--19751-- esp=0xB0755F38
>
>
>valgrind: the `impossible' happened:
> Killed by fatal signal
>Basic block ctr is approximately 503255235
>==19751== at 0xB7D74051: calc_exact_ST_dbld2 (ms_main.c:1269)
>
>
It looks like the crash happened when massif is assembling its final
report.
It seems that one of the pointers in the line
xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space
is equal to 0xe4e4e4e4 - a very clearly bogus pointer.
(The "stack overflow" message is meaningless in this context; it failed
to grow the stack to that address, so it decided that it was an overflow.)
Nick?
J
|
|
From: James B. <ja...@ha...> - 2005-03-09 16:28:55
|
Hi, I downloaded, compiled and ran the 2.4.0-rc1 release through the regtest suite on this FC3 box - the following 2 tests failed (which don't seem to be a problem): == 200 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) ==== Using the new version of memcheck on my application works a treat. No problems there. However, when I use the new version of massif, I get the following: ==================================================================== ==19751== ==19751== Stack overflow in thread 0: can't grow stack to 0xE4E4E4F4 --19751-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --19751-- si_code=1 Fault EIP: 0xB7D74051; Faulting address: 0xE4E4E4F4 --19751-- esp=0xB0755F38 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 503255235 ==19751== at 0xB7D74051: calc_exact_ST_dbld2 (ms_main.c:1269) sched status: running_tid=0 ==================================================================== ========================================= Note that the version of massif that came with the 2.2.0 release doesn't have a problem with my application. What is slightly confusing (at least to fools like me) is that my application finishes fine before generating the error - the last thing it does is print a 'finished' message. Any idea as to what is going on here? Cheers, James. James Begley -- Telephone: +354-575-2039. Marine Research Institute, Skulagata 4, P.O. Box 1390, 121 Reykjavik, Iceland. |
|
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: Aleksander S. <A....@os...> - 2005-03-09 13:09:01
|
> 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 > [...] > Please try it out. If it looks good, I think we should ship it. One bug found: http://bugs.kde.org/show_bug.cgi?id=101173 Best regards, Aleksander -- Aleksander Salwa OSMOSYS Technologies ul. Rozdzienskiego 188B Katowice, Poland http://www.osmosys.tv |
|
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: Oswald B. <os...@kd...> - 2005-03-09 06:22:07
|
On Tue, Mar 08, 2005 at 09:51:45PM -0600, Nicholas Nethercote wrote: > 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. > this is an evil hack. copyright years should be updated per file, not in bulk. ideally, a pre-checkin script would do it. but note also, that changing the case of a string is not exactly a copyright-worthy change. oh, well, i'm too pedantic. ;) > for i in `find . -name '*'` ; do > if [ -f $i ] ; then > IFS=' ' # paranoia. for bash, $'\n' would do, too for i in `find . -type f`; do -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
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: <js...@ac...> - 2005-03-09 04:07:34
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-09 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
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: Tom H. <to...@co...> - 2005-03-09 03:28:27
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-09 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 19855 Segmentation fault VALGRINDLIB=/tmp/valgrind.27254/valgrind/.in_place /tmp/valgrind.27254/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 204 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-09 03:22:14
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-09 03:15:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Tom H. <th...@cy...> - 2005-03-09 03:16:25
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-09 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 202 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-09 03:15:25
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-09 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 202 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-09 03:11:39
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-09 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 202 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-09 02:50:55
|
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:07
|
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 |