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
(15) |
2
(12) |
3
(11) |
4
(20) |
5
(6) |
|
6
(6) |
7
(7) |
8
(8) |
9
(17) |
10
(25) |
11
(27) |
12
(6) |
|
13
(28) |
14
(16) |
15
(20) |
16
(9) |
17
(26) |
18
(7) |
19
(25) |
|
20
(7) |
21
(18) |
22
(25) |
23
(15) |
24
(21) |
25
(32) |
26
(15) |
|
27
(23) |
28
(33) |
|
|
|
|
|
|
From: Eyal L. <ey...@ey...> - 2005-02-22 22:25:19
|
Jeremy Fitzhardinge wrote: > Eyal Lebedinsky wrote: > >> I think that this is not a simple memory shortage, but rather >> a shortage of some other resource. >> >> - Any VG resource I can set higher? >> - A linux kernel limit I should raise? > > > I'm sure you know the routine by now: > Please file a bug containing: http://bugs.kde.org/show_bug.cgi?id=100036 -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Tom H. <to...@co...> - 2005-02-22 22:16:00
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 22 February 2005 21:20, Nicholas Nethercote wrote:
> > This might be of interest to people here.
> >
> > ---------- Forwarded message ----------
> > Date: Tue, 22 Feb 2005 10:58:16 -0800
> > From: Michael Eager <ea...@ea...>
> > To: DW...@el..., gc...@gn..., gd...@so...
> > Subject: DWARF Website
>
> is it correct that we could use the LGPL'd libdwarf
> (see http://reality.sgi.com/davea/) instead of an own debugging reader now
> in Valgrind tools, i.e. not touching client space?
I've been thinking about suggesting libdwarf for a while. Another
project that I work on uses it to read DWARF and I think it would
probably have a number of advantages but I need to investigate it
some more.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-02-22 22:02:48
|
On Tuesday 22 February 2005 21:20, Nicholas Nethercote wrote: > This might be of interest to people here. > > ---------- Forwarded message ---------- > Date: Tue, 22 Feb 2005 10:58:16 -0800 > From: Michael Eager <ea...@ea...> > To: DW...@el..., gc...@gn..., gd...@so... > Subject: DWARF Website Hi, is it correct that we could use the LGPL'd libdwarf (see http://reality.sgi.com/davea/) instead of an own debugging reader now in Valgrind tools, i.e. not touching client space? I think this would make working with DWARF debug info much more simple. Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-02-22 20:20:17
|
This might be of interest to people here. ---------- Forwarded message ---------- Date: Tue, 22 Feb 2005 10:58:16 -0800 From: Michael Eager <ea...@ea...> To: DW...@el..., gc...@gn..., gd...@so... Subject: DWARF Website The DWARF Workgroup of the Free Standards Group (http://www.freestandards.org) is pleased to announce the creation of a website for the DWARF debugging format (http://dwarf.freestandards.org). The DWARF debugging format is used by compilers and debuggers to convey a description of the source code and how it is translated into machine code. This permits accurate and efficient debugging of programs. DWARF is used with a number of different toolchains such as the GNU Compiler Collection (GCC). There are three versions of the DWARF standard: DWARF 1.0 was originally used with System V and several toolchains. DWARF 2.0 added compression and support for C++, among other enhancements. DWARF 3.0 is an extension to the DWARF 2.0 format and adds support for new languages and improved debugging. We are also pleased to announce the public review of the Draft Standard for DWARF Version 3 which is available from the website. Following public review and resolution of comments on the Draft Standard, the DWARF Version 3 Standard will be released. There is also a mailing list for discussion of issues related to DWARF. Please register at http://mail.freestandards.org/cgi-bin/mailman/listinfo/dwarf-discuss. For additional information, please contact Michael Eager (mailto:ea...@ea...). -- Michael Eager, Chair, DWARF Workgroup ea...@ea... 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077 |
|
From: Tyler N. <tyl...@co...> - 2005-02-22 18:22:47
|
I have been using valgrind on a program that makes use of USB ioctls. Up until now I've just been using hacks in the program to get around the uninitialized memory complaints. I finally sat down and started to put the code into valgrind so it understands the ioctls. I have been successful, and have a build of valgrind that handles all the ioctls I use correctly. However now I'm trying to get it into a state so that I can submit a patch for it, and there is one circumstance that I don't know how to deal with. Basically one ioctl affects the memory written to by the next ioctl. Attached is the patch needed for these ioctls to work. The question is, is this the correct way to handle this, or is there a better way. Thanks, Tyler Nielsen <tyl...@co...> |
|
From: Jeremy F. <je...@go...> - 2005-02-22 17:09:21
|
Tom Hughes wrote:
>One of the threads (the manager thread? it is the first one created
>and isn't one of the four that sleep) isn't dieing, possibly because
>it isn't realising that all the other threads have died.
>
>I assume this has been triggered by one of your changes last night Jeremy?
>
I guess so. I'll look into it.
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-22 17:02:46
|
Eyal Lebedinsky wrote:
> I think that this is not a simple memory shortage, but rather
> a shortage of some other resource.
>
> - Any VG resource I can set higher?
> - A linux kernel limit I should raise?
I'm sure you know the routine by now:
Please file a bug containing:
* (ideally) a test program which lets us reproduce the problem, but
failing that
* the full, complete, unedited output of "valgrind <your options> -v
<your program>"
* and (in this case) --trace-syscalls=yes
Please include everything you've already mentioned in mail about this
bug so that its all in one place.
I really appreciate that you're testing Valgrind and finding some
interesting bugs, but it would be easier if you just file a bug report
up front for each issue, containing as much detail as you can. Your
system seems pretty complex, so I understand its hard to work out
exactly what the issue is, so include too much info - its much easier to
work with than not enough.
J
|
|
From: Tom H. <to...@co...> - 2005-02-22 15:22:36
|
In message <E1D...@gi...>
Tom Hughes <th...@cy...> wrote:
> Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-22 03:10:03 GMT
[ snipped ]
> pth_exit: valgrind ./pth_exit
> Could not read `pth_exit.stderr.exp'
> make: *** [regtest] Error 2
My RH 7.2, 7.3 and 8.0 boxes all locked up running the tests last
night. Two of them hung in pth_exit and the other in pth_cancel2 by
the looks of it.
I can also reproduce the hang on RH9 and FC3 with LD_ASSUME_KERNEL set
to 2.4.1 to force linuxthreads instead of NPTL.
One of the threads (the manager thread? it is the first one created
and isn't one of the four that sleep) isn't dieing, possibly because
it isn't realising that all the other threads have died.
I assume this has been triggered by one of your changes last night Jeremy?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eyal L. <ey...@ey...> - 2005-02-22 12:16:07
|
Eyal Lebedinsky wrote: > Running off latest cvs. > > I get this failure consistently, at the same stage of my testing > after a few hundred tests. My server aborts with these messages : > > VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. > VG_(get_memory_from_mmap): 33402662 bytes already allocated. > > Sorry. You could try using a tool that uses less memory; > eg. addrcheck instead of memcheck. I hoped for this problem to be gone now, what with the new lower memory usage promise. But no: VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. VG_(get_memory_from_mmap): 33599270 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. I think that this is not a simple memory shortage, but rather a shortage of some other resource. - Any VG resource I can set higher? - A linux kernel limit I should raise? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Tom H. <th...@cy...> - 2005-02-22 11:13:28
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-02-22 03:05:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow as_mmap: valgrind ./as_mmap as_shm: valgrind ./as_shm erringfds: valgrind ./erringfds fdleak_cmsg: valgrind --track-fds=yes ./fdleak_cmsg < /dev/null fdleak_creat: valgrind --track-fds=yes ./fdleak_creat < /dev/null fdleak_dup: valgrind --track-fds=yes ./fdleak_dup < /dev/null fdleak_dup2: valgrind --track-fds=yes ./fdleak_dup2 < /dev/null fdleak_fcntl: valgrind --track-fds=yes ./fdleak_fcntl < /dev/null fdleak_ipv4: valgrind --track-fds=yes ./fdleak_ipv4 < /dev/null fdleak_open: valgrind --track-fds=yes ./fdleak_open < /dev/null fdleak_pipe: valgrind --track-fds=yes ./fdleak_pipe < /dev/null fdleak_socketpair: valgrind --track-fds=yes ./fdleak_socketpair < /dev/null pth_atfork1: valgrind ./pth_atfork1 pth_cancel1: valgrind ./pth_cancel1 pth_cancel2: valgrind ./pth_cancel2 pth_cvsimple: valgrind ./pth_cvsimple pth_empty: valgrind ./pth_empty pth_exit: valgrind ./pth_exit Could not read `pth_exit.stderr.exp' make: *** [regtest] Error 2 |
|
From: Tom H. <th...@cy...> - 2005-02-22 11:13:26
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-22 03:00:06 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow as_mmap: valgrind ./as_mmap as_shm: valgrind ./as_shm erringfds: valgrind ./erringfds fdleak_cmsg: valgrind --track-fds=yes ./fdleak_cmsg < /dev/null fdleak_creat: valgrind --track-fds=yes ./fdleak_creat < /dev/null fdleak_dup: valgrind --track-fds=yes ./fdleak_dup < /dev/null fdleak_dup2: valgrind --track-fds=yes ./fdleak_dup2 < /dev/null fdleak_fcntl: valgrind --track-fds=yes ./fdleak_fcntl < /dev/null fdleak_ipv4: valgrind --track-fds=yes ./fdleak_ipv4 < /dev/null fdleak_open: valgrind --track-fds=yes ./fdleak_open < /dev/null fdleak_pipe: valgrind --track-fds=yes ./fdleak_pipe < /dev/null fdleak_socketpair: valgrind --track-fds=yes ./fdleak_socketpair < /dev/null pth_atfork1: valgrind ./pth_atfork1 pth_cancel1: valgrind ./pth_cancel1 pth_cancel2: valgrind ./pth_cancel2 pth_cvsimple: valgrind ./pth_cvsimple pth_empty: valgrind ./pth_empty pth_exit: valgrind ./pth_exit Could not read `pth_exit.stderr.exp' make: *** [regtest] Error 2 |
|
From: Tom H. <th...@cy...> - 2005-02-22 11:13:11
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-22 03:10:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow as_mmap: valgrind ./as_mmap as_shm: valgrind ./as_shm erringfds: valgrind ./erringfds fdleak_cmsg: valgrind --track-fds=yes ./fdleak_cmsg < /dev/null fdleak_creat: valgrind --track-fds=yes ./fdleak_creat < /dev/null fdleak_dup: valgrind --track-fds=yes ./fdleak_dup < /dev/null fdleak_dup2: valgrind --track-fds=yes ./fdleak_dup2 < /dev/null fdleak_fcntl: valgrind --track-fds=yes ./fdleak_fcntl < /dev/null fdleak_ipv4: valgrind --track-fds=yes ./fdleak_ipv4 < /dev/null fdleak_open: valgrind --track-fds=yes ./fdleak_open < /dev/null fdleak_pipe: valgrind --track-fds=yes ./fdleak_pipe < /dev/null fdleak_socketpair: valgrind --track-fds=yes ./fdleak_socketpair < /dev/null pth_atfork1: valgrind ./pth_atfork1 pth_cancel1: valgrind ./pth_cancel1 pth_cancel2: valgrind ./pth_cancel2 pth_cvsimple: valgrind ./pth_cvsimple pth_empty: valgrind ./pth_empty pth_exit: valgrind ./pth_exit Could not read `pth_exit.stderr.exp' make: *** [regtest] Error 2 |
|
From: Jeremy F. <je...@go...> - 2005-02-22 08:03:52
|
CVS commit by fitzhardinge: Update async-sigs expected output. M +0 -16 async-sigs.stderr.exp 1.4 --- valgrind/none/tests/async-sigs.stderr.exp #1.3:1.4 @@ -1,26 +1,10 @@ -Process terminating with default action of signal 7 (SIGBUS) - at 0x........: test (async-sigs.c:78) - by 0x........: main (async-sigs.c:117) -Process terminating with default action of signal 7 (SIGBUS) - at 0x........: test (async-sigs.c:78) - by 0x........: main (async-sigs.c:117) -Process terminating with default action of signal 7 (SIGBUS) - at 0x........: pause (in /...libc...) - by 0x........: main (async-sigs.c:117) - - - -Process terminating with default action of signal 7 (SIGBUS) - at 0x........: pause (in /...libc...) - by 0x........: main (async-sigs.c:117) - |
|
From: Tom H. <to...@co...> - 2005-02-22 03:28:20
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-22 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow (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 ---------------------------------------- == 205 tests, 8 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) none/tests/sigcontext (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-22 03:23:17
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-22 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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, 7 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) none/tests/async-sigs (stderr) none/tests/sigcontext (stdout) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-02-22 03:16:10
|
CVS commit by fitzhardinge:
Don't print non-coredumping fatal signals at normal verbosity levels..
Also, only always-print coredumping signals which were sent by the kernel
(ie, don't always print ones sent by kill, etc).
M +1 -1 vg_signals.c 1.128
--- valgrind/coregrind/vg_signals.c #1.127:1.128
@@ -1296,5 +1296,5 @@ static void vg_default_action(const vki_
}
- if (VG_(clo_verbosity) != 0 || could_core) {
+ if (VG_(clo_verbosity) > 1 || (could_core && info->si_code > VKI_SI_USER)) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg, "Process terminating with default action of signal %d (%s)%s",
|
|
From: Robert W. <rj...@du...> - 2005-02-22 03:09:26
|
CVS commit by rjwalsh: Ignore pointer-trace executable. M +1 -0 .cvsignore 1.32 --- valgrind/memcheck/tests/.cvsignore #1.31:1.32 @@ -47,4 +47,5 @@ null_socket overlap +pointer-trace post-syscall realloc1 |
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:45:31
|
CVS commit by fitzhardinge: Filter leak-check message. M +2 -2 pointer-trace.stderr.exp 1.2 M +1 -0 pointer-trace.vgtest 1.2 --- valgrind/memcheck/tests/pointer-trace.vgtest #1.1:1.2 @@ -1,2 +1,3 @@ prog: pointer-trace vgopts: --leak-check=yes +stderr_filter: filter_leak_check_size --- valgrind/memcheck/tests/pointer-trace.stderr.exp #1.1:1.2 @@ -1,5 +1,5 @@ searching for pointers to 1 not-freed blocks. -checked 2380352 bytes. +checked ... bytes. LEAK SUMMARY: @@ -16,5 +16,5 @@ For counts of detected errors, rerun with: -v searching for pointers to 1 not-freed blocks. -checked 2380348 bytes. +checked ... bytes. 1048576 bytes in 1 blocks are possibly lost in loss record 1 of 1 |
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:40:04
|
CVS commit by fitzhardinge:
It is an absolute no-no to change the signal handlers, so fix the
leak-checking code to avoid it. The core fault signal handler now allows
tools to register a catcher for when they want to see SIGSEGV/BUS,
as the leak-checker does. Also, add a test case to make sure
pointer-tracing avoids all the possible traps.
A memcheck/tests/pointer-trace.c 1.1 [no copyright]
A memcheck/tests/pointer-trace.stderr.exp 1.1
A memcheck/tests/pointer-trace.vgtest 1.1
M +2 -2 addrcheck/ac_main.c 1.78
M +19 -0 coregrind/vg_signals.c 1.127
M +5 -0 include/tool.h.base 1.23
M +18 -54 memcheck/mac_leakcheck.c 1.17
M +2 -2 memcheck/mc_main.c 1.64
M +3 -0 memcheck/tests/Makefile.am 1.67
--- valgrind/include/tool.h.base #1.22:1.23
@@ -505,4 +505,9 @@
extern Bool VG_(is_valgrind_addr)(Addr a);
+/* Register an interest in apparently internal faults; used code which
+ wanders around dangerous memory (ie, leakcheck). The catcher is
+ not expected to return. */
+extern void VG_(set_fault_catcher)(void (*catcher)(Int sig, Addr addr));
+
/* initialize shadow pages in the range [p, p+sz) This calls
init_shadow_page for each one. It should be a lot more efficient
--- valgrind/addrcheck/ac_main.c #1.77:1.78
@@ -1124,6 +1124,6 @@ static
Bool ac_is_valid_64k_chunk ( UInt chunk_number )
{
- sk_assert(chunk_number >= 0 && chunk_number < 65536);
- if (IS_DISTINGUISHED_SM(primary_map[chunk_number])) {
+ sk_assert(chunk_number >= 0 && chunk_number < PRIMARY_SIZE);
+ if (primary_map[chunk_number] == DSM_NOTADDR) {
/* Definitely not in use. */
return False;
--- valgrind/memcheck/mac_leakcheck.c #1.16:1.17
@@ -47,6 +47,9 @@ jmp_buf memscan_jmpbuf;
static
-void vg_scan_all_valid_memory_sighandler ( Int sigNo )
+void vg_scan_all_valid_memory_catcher ( Int sigNo, Addr addr )
{
+ if (0)
+ VG_(printf)("OUCH! sig=%d addr=%p\n", sigNo, addr);
+ if (sigNo == VKI_SIGSEGV || sigNo == VKI_SIGBUS)
__builtin_longjmp(memscan_jmpbuf, 1);
}
@@ -77,46 +79,11 @@ UInt vg_scan_all_valid_memory ( Bool is_
volatile Bool anyValid;
volatile Addr pageBase, addr;
- volatile UInt res, numPages, page, primaryMapNo;
+ volatile UInt numPages, page, primaryMapNo;
volatile UInt page_first_word, nWordsNotified;
+ vki_sigset_t sigmask;
- struct vki_sigaction sigbus_saved;
- struct vki_sigaction sigbus_new;
- struct vki_sigaction sigsegv_saved;
- struct vki_sigaction sigsegv_new;
- vki_sigset_t blockmask_saved;
- vki_sigset_t unblockmask_new;
-
- /* Temporarily install a new sigsegv and sigbus handler, and make
- sure SIGBUS, SIGSEGV and SIGTERM are unblocked. (Perhaps the
- first two can never be blocked anyway?) */
-
- sigbus_new.ksa_handler = vg_scan_all_valid_memory_sighandler;
- sigbus_new.sa_flags = VKI_SA_ONSTACK | VKI_SA_RESTART;
- sigbus_new.sa_restorer = NULL;
- res = VG_(sigemptyset)( &sigbus_new.sa_mask );
- sk_assert(res == 0);
-
- sigsegv_new.ksa_handler = vg_scan_all_valid_memory_sighandler;
- sigsegv_new.sa_flags = VKI_SA_ONSTACK | VKI_SA_RESTART;
- sigsegv_new.sa_restorer = NULL;
- res = VG_(sigemptyset)( &sigsegv_new.sa_mask );
- sk_assert(res == 0+0);
-
- res = VG_(sigemptyset)( &unblockmask_new );
- res |= VG_(sigaddset)( &unblockmask_new, VKI_SIGBUS );
- res |= VG_(sigaddset)( &unblockmask_new, VKI_SIGSEGV );
- res |= VG_(sigaddset)( &unblockmask_new, VKI_SIGTERM );
- sk_assert(res == 0+0+0);
-
- res = VG_(sigaction)( VKI_SIGBUS, &sigbus_new, &sigbus_saved );
- sk_assert(res == 0+0+0+0);
-
- res = VG_(sigaction)( VKI_SIGSEGV, &sigsegv_new, &sigsegv_saved );
- sk_assert(res == 0+0+0+0+0);
-
- res = VG_(sigprocmask)( VKI_SIG_UNBLOCK, &unblockmask_new, &blockmask_saved );
- sk_assert(res == 0+0+0+0+0+0);
+ VG_(sigprocmask)(VKI_SIG_SETMASK, NULL, &sigmask);
+ VG_(set_fault_catcher)(vg_scan_all_valid_memory_catcher);
- /* The signal handlers are installed. Actually do the memory scan. */
numPages = 1 << (32-VKI_PAGE_SHIFT);
sk_assert(numPages == 1048576);
@@ -155,10 +122,10 @@ UInt vg_scan_all_valid_memory ( Bool is_
/* Ok, we have to prod cautiously at the page and see if it
explodes or not. */
- if (__builtin_setjmp(memscan_jmpbuf) == 0) {
- /* try this ... */
+ if (VG_(is_addressable)(pageBase, sizeof(UInt), VKI_PROT_READ) &&
+ __builtin_setjmp(memscan_jmpbuf) == 0) {
page_first_word = * (volatile UInt*)pageBase;
/* we get here if we didn't get a fault */
/* Scan the page */
- for (addr = pageBase; addr < pageBase+VKI_PAGE_SIZE; addr += 4) {
+ for (addr = pageBase; addr < pageBase+VKI_PAGE_SIZE; addr += sizeof(void *)) {
if (is_valid_address(addr)) {
nWordsNotified++;
@@ -170,4 +137,8 @@ UInt vg_scan_all_valid_memory ( Bool is_
fault, which in turn caused the signal handler to longjmp.
Ignore this page. */
+
+ /* We need to restore the signal mask, because we were
+ longjmped out of a signal handler. */
+ VG_(sigprocmask)(VKI_SIG_SETMASK, &sigmask, NULL);
if (0)
VG_(printf)(
@@ -178,13 +149,6 @@ UInt vg_scan_all_valid_memory ( Bool is_
}
- /* Restore signal state to whatever it was before. */
- res = VG_(sigaction)( VKI_SIGBUS, &sigbus_saved, NULL );
- sk_assert(res == 0 +0);
-
- res = VG_(sigaction)( VKI_SIGSEGV, &sigsegv_saved, NULL );
- sk_assert(res == 0 +0 +0);
-
- res = VG_(sigprocmask)( VKI_SIG_SETMASK, &blockmask_saved, NULL );
- sk_assert(res == 0 +0 +0 +0);
+ VG_(sigprocmask)(VKI_SIG_SETMASK, &sigmask, NULL);
+ VG_(set_fault_catcher)(NULL);
return nWordsNotified;
--- valgrind/memcheck/mc_main.c #1.63:1.64
@@ -1523,6 +1523,6 @@ static
Bool mc_is_valid_64k_chunk ( UInt chunk_number )
{
- sk_assert(chunk_number >= 0 && chunk_number < 65536);
- if (IS_DISTINGUISHED_SM(primary_map[chunk_number])) {
+ sk_assert(chunk_number >= 0 && chunk_number < PRIMARY_SIZE);
+ if (primary_map[chunk_number] == DSM_NOTADDR) {
/* Definitely not in use. */
return False;
--- valgrind/coregrind/vg_signals.c #1.126:1.127
@@ -1687,4 +1687,15 @@ Bool VG_(extend_stack)(Addr addr, UInt m
}
+static void (*fault_catcher)(Int sig, Addr addr);
+
+void VG_(set_fault_catcher)(void (*catcher)(Int, Addr))
+{
+ if (catcher != NULL && fault_catcher != NULL)
+ VG_(core_panic)("Fault catcher is already registered");
+
+ fault_catcher = catcher;
+}
+
+
/*
Recieve a sync signal from the host.
@@ -1835,4 +1846,12 @@ void vg_sync_signalhandler ( Int sigNo,
}
+ /* Check to see if someone is interested in faults. */
+ if (fault_catcher) {
+ (*fault_catcher)(sigNo, (Addr)info->_sifields._sigfault._addr);
+
+ /* If the catcher returns, then it didn't handle the fault,
+ so carry on panicing. */
+ }
+
/* If resume_scheduler returns or its our fault, it means we
don't have longjmp set up, implying that we weren't running
--- valgrind/memcheck/tests/Makefile.am #1.66:1.67
@@ -51,4 +51,5 @@
null_socket.stderr.exp null_socket.vgtest \
overlap.stderr.exp overlap.stdout.exp overlap.vgtest \
+ pointer-trace.vgtest pointer-trace.stdout.exp pointer-trace.stderr.exp \
post-syscall.stderr.exp post-syscall.stdout.exp post-syscall.vgtest \
pth_once.stderr.exp pth_once.stdout.exp pth_once.vgtest \
@@ -90,4 +91,5 @@
nanoleak new_nothrow \
null_socket overlap \
+ pointer-trace \
post-syscall \
realloc1 realloc2 realloc3 \
@@ -143,4 +145,5 @@
null_socket_SOURCES = null_socket.c
overlap_SOURCES = overlap.c
+pointer_trace_SOURCES = pointer-trace.c
post_syscall_SOURCES = post-syscall.c
realloc1_SOURCES = realloc1.c
|
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:34:37
|
CVS commit by fitzhardinge:
Implement sys_sched_rr_get_interval. Tested in posixtestsuite.
M +1 -0 core.h 1.89
M +12 -0 vg_syscalls.c 1.253
M +1 -1 x86-linux/syscalls.c 1.25
--- valgrind/coregrind/vg_syscalls.c #1.252:1.253
@@ -4712,4 +4712,16 @@ POST(sys_sched_getparam)
}
+PRE(sys_sched_rr_get_interval, 0)
+{
+ PRINT("sched_rr_get_interval ( %d, %p )", arg1, arg2);
+ PRE_REG_READ2(int, "sched_rr_get_interval", vki_pid_t, pid, struct vki_timespec *, tp);
+ SYS_PRE_MEM_WRITE("sched_rr_get_interval(tp)", arg2, sizeof(struct vki_timespec));
+}
+
+POST(sys_sched_rr_get_interval)
+{
+ POST_MEM_WRITE(arg2, sizeof(struct vki_timespec));
+}
+
PRE(sys_select, MayBlock)
{
--- valgrind/coregrind/core.h #1.88:1.89
@@ -1381,4 +1381,5 @@ GEN_SYSCALL_WRAPPER(sys_munlockall);
GEN_SYSCALL_WRAPPER(sys_sched_setparam);
GEN_SYSCALL_WRAPPER(sys_sched_getparam);
+GEN_SYSCALL_WRAPPER(sys_sched_rr_get_interval);
GEN_SYSCALL_WRAPPER(sys_sched_setscheduler);
GEN_SYSCALL_WRAPPER(sys_sched_getscheduler);
--- valgrind/coregrind/x86-linux/syscalls.c #1.24:1.25
@@ -894,5 +894,5 @@ const struct SyscallTableEntry VGA_(sysc
GENX_(__NR_sched_get_priority_min, sys_sched_get_priority_min),// 160
- // (__NR_sched_rr_get_interval, sys_sched_rr_get_interval), // 161 */*
+ GENXY(__NR_sched_rr_get_interval, sys_sched_rr_get_interval), // 161 */*
GENXY(__NR_nanosleep, sys_nanosleep), // 162
GENX_(__NR_mremap, sys_mremap), // 163
|
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:33:59
|
CVS commit by fitzhardinge:
Always report core-dumping signals. If the client gets a fatal core-dumping
signal, always report it, since it indicates a real program bug.
M +1 -1 vg_signals.c 1.126
--- valgrind/coregrind/vg_signals.c #1.125:1.126
@@ -1296,5 +1296,5 @@ static void vg_default_action(const vki_
}
- if (VG_(clo_verbosity) != 0 && (could_core || VG_(clo_verbosity) > 1)) {
+ if (VG_(clo_verbosity) != 0 || could_core) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg, "Process terminating with default action of signal %d (%s)%s",
|
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:33:04
|
CVS commit by fitzhardinge:
SIGCONT has special properties with respect to interrupting/restarting syscalls.
The easiest thing to do is let the kernel handle it, so we do - only install
a handler for SIGCONT if the client asks for it.
M +11 -0 vg_signals.c 1.125
--- valgrind/coregrind/vg_signals.c #1.124:1.125
@@ -251,4 +251,15 @@ void calculate_SKSS_from_SCSS ( SKSS* ds
break;
+ case VKI_SIGCONT:
+ /* Let the kernel handle SIGCONT unless the client is actually
+ catching it. */
+ if (vg_scss.scss_per_sig[sig].scss_handler == VKI_SIG_DFL)
+ skss_handler = VKI_SIG_DFL;
+ else if (vg_scss.scss_per_sig[sig].scss_handler == VKI_SIG_IGN)
+ skss_handler = VKI_SIG_IGN;
+ else
+ skss_handler = vg_async_signalhandler;
+ break;
+
default:
if (sig == VKI_SIGVGKILL)
|
|
From: Jeremy F. <je...@go...> - 2005-02-22 02:32:04
|
CVS commit by fitzhardinge:
An mlock() will split a mapping in /proc/self/maps, so we need to update the
Segment list to match. These splits can happen even if the mlock() ends up
failing, so do it in the PRE() function.
M +2 -0 core.h 1.88
M +17 -0 vg_syscalls.c 1.252
--- valgrind/coregrind/vg_syscalls.c #1.251:1.252
@@ -1493,6 +1493,20 @@ PRE(sys_sched_setscheduler, 0)
PRE(sys_mlock, MayBlock)
{
+ Addr start, end;
+
PRINT("sys_mlock ( %p, %llu )", arg1, (ULong)arg2);
PRE_REG_READ2(long, "mlock", unsigned long, addr, vki_size_t, len);
+
+ if (!VG_(valid_client_addr)((Addr)arg1, arg2, tid, "mlock"))
+ SYSRES = -VKI_ENOMEM;
+
+ /* mlock() causes the kernel's mappings to be split, so make sure
+ the segment list matches it. This can happen even if the
+ mlock() call ultimately fails, so split here rather than in
+ POST(). */
+ start = PGROUNDDN(arg1);
+ end = PGROUNDUP(arg1+arg2);
+ VG_(split_segment)(start);
+ VG_(split_segment)(end);
}
@@ -1501,4 +1515,7 @@ PRE(sys_munlock, MayBlock)
PRINT("sys_munlock ( %p, %llu )", arg1, (ULong)arg2);
PRE_REG_READ2(long, "munlock", unsigned long, addr, vki_size_t, len);
+
+ if (!VG_(valid_client_addr)((Addr)arg1, arg2, tid, "munlock"))
+ SYSRES = -VKI_ENOMEM;
}
--- valgrind/coregrind/core.h #1.87:1.88
@@ -1248,4 +1248,6 @@ extern Bool VG_(seg_contains)(const
extern Bool VG_(seg_overlaps)(const Segment *s, Addr ptr, SizeT size);
+extern Segment *VG_(split_segment)(Addr a);
+
extern void VG_(pad_address_space) (Addr start);
extern void VG_(unpad_address_space)(Addr start);
|
|
From: Robert W. <rj...@du...> - 2005-02-22 01:55:41
|
CVS commit by rjwalsh: Ignore the addressable executable. M +1 -0 .cvsignore 1.31 --- valgrind/memcheck/tests/.cvsignore #1.30:1.31 @@ -1,4 +1,5 @@ Makefile.in Makefile +addressable badaddrvalue badfree |
|
From: Robert W. <rj...@du...> - 2005-02-22 01:53:05
|
CVS commit by rjwalsh: This test doesn't compile on a system without Valgrind already installed if I don't change the memcheck.h #include. M +1 -1 addressable.c 1.2 --- valgrind/memcheck/tests/addressable.c #1.1:1.2 @@ -1,4 +1,4 @@ /* Test different kinds of addressability and definedness */ -#include <valgrind/memcheck.h> +#include "../memcheck.h" #include <sys/mman.h> #include <stdio.h> |