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: Julian S. <js...@ac...> - 2005-02-25 23:45:34
|
Nice summary. Definitely a good thing. > > - increase the default --num-callers size to 12 > > Yes! I was about to propose this. 4 has been way too small for a long > time. Also, the default --leak-resolution=low (2 frames matches) is too > low as well; I think it should default to "med". Yes, perhaps time to increase --num-callers. Problem with large values is that error messages take up tons of screen space. Oh well. Default 8 ? 12 ? > 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). Indeed, I am not the only one: the V that comes packaged with SuSE seems to already have been defaulted to memcheck, presumably by the SuSE folks themselves. (iow, "valgrind ls" works fine on SuSE). > I find --show-reachable is too noisy for common use. I agree. I hesitate to run the leak checker by default at exit. It can cause a huge amount of disk activity because it inspects bits of address space that had been swapped out during long runs of leaky programs, and which then gets forced back in as the checker traverses it all. But perhaps we should. In an underhand way it creates the expectation amongst programmers that their programs should have no detectable leaks, and that leaks will be tested for routinely -- every time V is run. And it helps our software engineering too. Currently the checker is basically an optional component and doesn't get tested enough. If it was engaged by default, we would know much sooner if there was anything broken about it. J |
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 22:46:46
|
On Fri, 25 Feb 2005, Robert Walsh wrote: >>> And should we consider defaulting to memcheck again? >> >> I don't think so; it is still the best way to imply that there are other >> tools. > > I vote for a default too. I use memcheck 95% of the time and it's > getting tiring typing those extra letters :-) That's what the .valgrindrc file is for :) N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 22:42:44
|
On Thu, 24 Feb 2005, Jeremy Fitzhardinge wrote: >>> * big-bang shadow allocation causes problems on kernels that don't >>> do overcommitment >>> >>> * a fixed partitioning scheme is less appropriate if we move towards >>> compressed representations of shadow memory, since that compression >>> ratio could be variable >> >> >> Plus all the other problems mentioned in bug #82301, which we've talked >> about at length multiple times in the past. > > The only additional problem in that bug is the difficulty with loading large > symbol files, which won't be helped by the superblock scheme at all; it will > be made worse. But that's OK, because the symtab reader needs to be fixed > anyway. That's not the only additional problem. Sometimes Valgrind tools run out of memory in their space when the client space is not full, and vice versa. N |
|
From: Robert W. <rj...@du...> - 2005-02-25 22:40:52
|
> > And should we consider defaulting to memcheck again? >=20 > I don't think so; it is still the best way to imply that there are other= =20 > tools. I vote for a default too. I use memcheck 95% of the time and it's getting tiring typing those extra letters :-) --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 22:19:44
|
On Fri, 25 Feb 2005, Julian Seward wrote: > I'm already on the case. Basically the Intel compiler (icc 8) will tell > you all about this, and much, much more. Good. Do you think we should not worry about it for the CVS code and 2.4.0 then? > I didn't know that gcc4 is more picky than gcc3. That's a good > thing. I've noticed GCC getting slowly pickier through the 3.X series, and now this big jump in pickiness with 4.0.0. N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 21:54:09
|
On Fri, 25 Feb 2005, Jeremy Fitzhardinge wrote: >> - make --leak-check=yes the default for Memcheck > > Maybe. For simply running a program its a good default, but running a > shell script (with lots of exits) can be hit quite hard by --leak-check > (though its a bit more efficient now). Also, if a program is using > DO_LEAK_CHECK, they might not want an implicit one too. I argue that scripts and programs using DO_LEAK_CHECK are in the minority. > And should we consider defaulting to memcheck again? I don't think so; it is still the best way to imply that there are other tools. N |
|
From: Jeremy F. <je...@go...> - 2005-02-25 21:49:05
|
Nicholas Nethercote wrote:
> - make --leak-check=yes the default for Memcheck
Maybe. For simply running a program its a good default, but running a
shell script (with lots of exits) can be hit quite hard by --leak-check
(though its a bit more efficient now). Also, if a program is using
DO_LEAK_CHECK, they might not want an implicit one too.
> - increase the default --num-callers size to 12
Yes! I was about to propose this. 4 has been way too small for a long
time. Also, the default --leak-resolution=low (2 frames matches) is too
low as well; I think it should default to "med".
And should we consider defaulting to memcheck again?
> And I think that's most useful because the survey responses I've
> received in the last year (14 of them) almost everyone uses
> --leak-check=yes all the time, and most people immediately crank up
> --num-callers to at least 10 (and sometimes much higher, eg. 40).
> --show-reachable=yes is also pretty popular, but I don't think it's
> quite popular enough to make the default.
I find --show-reachable is too noisy for common use.
> So, the quick start would then be shorter, since I wouldn't have to
> explain those options. I think it's currently already too long, but
> it's only a draft.
>
> I think this document and these settings changes would lower the bar
> for new users to get Memcheck working usefully as quickly as possible,
> which is what 95% of users would want, and is something we should aim
> for.
>
> Comments?
>
> N
>
>------------------------------------------------------------------------
>
>Valgrind quick start
>--------------------
>This document contains the minimum information you should know to start
>detecting memory errors in your program with Valgrind.
>
>The Valgrind distribution has multiple tools. The memory checking tool
>(called Memcheck) can detect many common memory errors such as:
>
>- touching memory you shouldn't (eg. overrunning heap block boundaries)
>- using values before they have been initialized
>- incorrect freeing of memory, such as double-freeing heap blocks
>- memory leaks
>
>Here's how to use it.
>
>1. Preparing your program. Compile your program with debugging information so
>that Memcheck's error messages include exact line numbers.
>
>
I'd add "(-g)" after "debugging information", just to be explicit.
>2. Running your program under Memcheck. If you normally run your program
>like this:
>
> myprog arg1 arg2 arg3
>
>Use this command line:
>
> valgrind --tool=memcheck --num-callers=40 --leak-check=yes myprog arg2 arg2 arg3
>
>The --tool option invokes Memcheck. The --num-callers option asks for big
>stack traces, which make error messages more informative. The --leak-check
>option turns on the memory leak detector.
>
>Your program will run much slower (eg. 20 to 30 times) than normal.
>Memcheck will describe any errors it detects. When your program terminates,
>Memcheck will describe any memory leaks it detects.
>
>3. Interpreting Memcheck's output. Here's an example C program with two
>memory errors.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int f(void)
> {
> int* x = malloc(10 * sizeof(int));
> x[10] = 0; // problem 1: heap block overrun
> return; // problem 2: memory leak -- x not freed
> }
>
> int main(void)
> {
> f();
> return 0;
> }
>
>Most error messages look like the following, which describes problem 1, the
>heap block overrun:
>
> ==19182== Invalid write of size 4
> ==19182== at 0x804838F: f (a.c:8)
> ==19182== by 0x80483AB: main (a.c:14)
> ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd
> ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
> ==19182== by 0x8048385: f (a.c:7)
> ==19182== by 0x80483AB: main (a.c:14)
>
>Things to notice:
>- There is a lot of information in each error message; read it carefully.
>
>- The 19182 is the process ID; it's usually unimportant.
>
>- The first line ("Invalid write...") tells you what the error is. Here,
> the program wrote to some memory it should not have due to a heap block
> overrun.
>
>- Below the first line is a stack trace. Stack traces can get quite large,
> and be confusing, especially if you are using the C++ STL. Reading them
> from the bottom up can help. If the stack trace is not big enough, use a
> bigger --num-callers option.
>
>- The addresses (eg. 0x804838F) are usually unimportant, but occasionally
> crucial for tracking down weirder bugs.
>
>- Some error messages, such as this one, have a second component which
> describes the memory address involved, and possibly give another stack
> trace showing where it was allocated or freed.
>
>
I would explicitly, but briefly, describe the Address block.
Looks good.
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 21:41:47
|
Nicholas Nethercote wrote:
> I had a similar problem last night on my Debian 3.0 box. Strange
> thing was, whether pth_exit hung or not seemed to depend on the value
> of the --prefix path given to ./configure! I had two clean checkouts,
> the only difference was the --prefix path, and one hung while the
> other didn't. So I reconfigured, swapping the prefix paths, and this
> time the other one hung. Very strange.
I checked in a signals-related fix last night which could well fix it.
I have no idea why --prefix would affect it though.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 20:34:19
|
On Tue, 22 Feb 2005, Jeremy Fitzhardinge 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. I had a similar problem last night on my Debian 3.0 box. Strange thing was, whether pth_exit hung or not seemed to depend on the value of the --prefix path given to ./configure! I had two clean checkouts, the only difference was the --prefix path, and one hung while the other didn't. So I reconfigured, swapping the prefix paths, and this time the other one hung. Very strange. N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-25 20:04:09
|
Hi, I just, for the first time, found myself in the situation of introducing Valgrind to multiple people. And so I realised that we are sorely lacking a "Quick Start Guide", which tells people the minimum amount of information required to start using Memcheck. And so I wrote one. It's attached. Feedback is welcome. I think this would be useful to make official, either as part of the user manual, or maybe as a separate doc. I can HTML it and commit it if people think this is a good idea. As a result of writing this, I think we should do the following: - make --leak-check=yes the default for Memcheck - increase the default --num-callers size to 12 Why? Partly because in the quick start I immediately suggest starting with this command line: valgrind --tool=memcheck --num-callers=40 --leak-check=yes ... because that's what I think is most useful. And I think that's most useful because the survey responses I've received in the last year (14 of them) almost everyone uses --leak-check=yes all the time, and most people immediately crank up --num-callers to at least 10 (and sometimes much higher, eg. 40). --show-reachable=yes is also pretty popular, but I don't think it's quite popular enough to make the default. So, the quick start would then be shorter, since I wouldn't have to explain those options. I think it's currently already too long, but it's only a draft. I think this document and these settings changes would lower the bar for new users to get Memcheck working usefully as quickly as possible, which is what 95% of users would want, and is something we should aim for. Comments? N |
|
From: Julian S. <js...@ac...> - 2005-02-25 14:20:31
|
> Any thoughts about this? The "char != signed char" idea seems crazy, but
> maybe it is worth cleaning up our intermixing of signed and unsigned types
> a bit? Or perhaps we could use -no-pedantic-signed-warnings, or whatever
> the option is, if there is one? Once GCC 4.0.0 is released, we'll have to
> deal with this, because I'm sure people will freak out at the huge numbers
> of warnings we get with it.
I'm already on the case. Basically the Intel compiler (icc 8) will tell
you all about this, and much, much more.
pub/libvex_basictypes.h says:
typedef unsigned char UChar;
typedef signed char Char;
typedef char HChar; /* signfulness depends on host */
/* Only to be used for printf etc
format strings */
and I intend to push those types through the entire code base so
it compiles cleanly with icc (vex is already largely done).
I guess that would keep gcc4 quiet too. I have to say I think
the more aggressive typechecking from gcc4/icc can only be a good
thing in the end; we should fix our code rather than add
flags to silence warnings.
HChar is what you need for literal strings, and has unknown
signfulness (whatever the host has).
Placating icc when it is in ultra-paranoid mode (-Wall, which is
far more paranoid than gcc's interpretation of same) is a bit
of a drag, but just occasionally it comes up with something
which could save hours of bug-hunting in the future, like this:
priv/guest-x86/toIR.c(323): remark #810: conversion from "int" to
"UShort={unsigned short}" may lose significant bits
vge->len[vge->n_used-1] += size;
(size is Int, len[] is UShort[]). Icc is quite correct here in
that some external guarantee has to be provided that len[] values
will not overflow. gcc (3.X, at least) makes no comment.
I didn't know that gcc4 is more picky than gcc3. That's a good
thing.
J
|
|
From: Tom H. <th...@cy...> - 2005-02-25 09:50:25
|
CVS commit by thughes: Update .cvsignore file for new tests. M +4 -0 .cvsignore 1.33 --- valgrind/memcheck/tests/.cvsignore #1.32:1.33 @@ -29,4 +29,8 @@ inits inline +leak-0 +leak-cycle +leak-regroot +leak-tree malloc1 malloc2 |
|
From: Tom H. <th...@cy...> - 2005-02-25 08:23:21
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-02-25 03:05:02 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-25 08:23:00
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-25 03:00:02 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-25 05:53:15
|
CVS commit by fitzhardinge:
Squash warning.
M +1 -1 faultstatus.c 1.5
--- valgrind/none/tests/faultstatus.c #1.4:1.5
@@ -125,5 +125,5 @@ static void test9()
static int limit[2] = { 0, 10 };
- asm volatile ("bound %0, %1" : : "r" (11), "m" (limit));
+ asm volatile ("bound %0, %1" : : "r" (11), "m" (limit[0]));
}
#endif /* __i386__ */
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:39:59
|
CVS commit by fitzhardinge:
Oops. I've had this sitting in my tree for ages, but forgot to check it in.
Properly restore the signal mask on return from a signal handler.
M +1 -0 signal.c 1.15
--- valgrind/coregrind/x86/signal.c #1.14:1.15
@@ -554,4 +554,5 @@ static Bool restore_vg_sigframe(ThreadSt
tst->sig_mask = frame->mask;
+ tst->eff_sig_mask = frame->mask;
if (VG_(needs).shadow_regs) {
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:35:46
|
CVS commit by fitzhardinge:
Close a couple of small leaks.
M +2 -0 ume.c 1.40
M +1 -0 vg_main.c 1.253
--- valgrind/coregrind/vg_main.c #1.252:1.253
@@ -810,4 +810,5 @@ static char **fix_environment(char **ori
}
+ free(inject_path);
ret[envc] = NULL;
--- valgrind/coregrind/ume.c #1.39:1.40
@@ -420,4 +420,5 @@ static int load_ELF(char *hdr, int len,
info->interp_base = (ESZ(Addr))base;
+ free(interp->p);
free(interp);
} else
@@ -429,4 +430,5 @@ static int load_ELF(char *hdr, int len,
info->init_eip = (Addr)entry;
+ free(e->p);
free(e);
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:34:48
|
CVS commit by fitzhardinge:
Use a more useful format when printing an "LDT limit exceeded" message.
M +1 -1 ldt.c 1.9
--- valgrind/coregrind/x86-linux/ldt.c #1.8:1.9
@@ -247,5 +247,5 @@ Addr VG_(do_useseg) ( UInt seg_selector,
VG_(message)(
Vg_UserMsg,
- "Warning: segment access: virtual addr %d exceeds segment limit of %d",
+ "Warning: segment access: virtual addr %p exceeds segment limit of %x",
virtual_addr, limit
);
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:33:59
|
CVS commit by fitzhardinge:
Allocate enough space for the terminal \0 when allocating space for the filename.
M +1 -1 vg_procselfmaps.c 1.19
--- valgrind/coregrind/vg_procselfmaps.c #1.18:1.19
@@ -241,5 +241,5 @@ void VG_(parse_procselfmaps) (
/* Minor hack: put a '\0' at the filename end for the call to
`record_mapping', then restore the old char with `tmp'. */
- filename = VG_(arena_malloc)(VG_AR_CORE, i_eol-i);
+ filename = VG_(arena_malloc)(VG_AR_CORE, i_eol-i+1);
VG_(memcpy)(filename, &procmap_buf[i], i_eol-i);
filename[i_eol - i] = '\0';
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:32:25
|
CVS commit by fitzhardinge:
Fix a long-standing bug in the core-dumper, revealed by the
avoid-device-maps patch.
M +15 -12 vg_signals.c 1.132
--- valgrind/coregrind/vg_signals.c #1.131:1.132
@@ -1096,5 +1096,5 @@ static void make_coredump(ThreadId tid,
Elf32_Phdr *phdrs;
Int num_phdrs;
- Int i;
+ Int i, idx;
UInt off;
struct note *notelist, *note;
@@ -1186,13 +1186,15 @@ static void make_coredump(ThreadId tid,
off = PGROUNDUP(off);
- for(seg = VG_(first_segment)(), i = 1;
+ for(seg = VG_(first_segment)(), idx = 1;
seg != NULL;
- seg = VG_(next_segment)(seg), i++) {
+ seg = VG_(next_segment)(seg)) {
if (!may_dump(seg))
continue;
- fill_phdr(&phdrs[i], seg, off, (seg->len + off) < max_size);
+ fill_phdr(&phdrs[idx], seg, off, (seg->len + off) < max_size);
- off += phdrs[i].p_filesz;
+ off += phdrs[idx].p_filesz;
+
+ idx++;
}
@@ -1206,18 +1208,19 @@ static void make_coredump(ThreadId tid,
VG_(lseek)(core_fd, phdrs[1].p_offset, VKI_SEEK_SET);
- for(seg = VG_(first_segment)(), i = 1;
+ for(seg = VG_(first_segment)(), idx = 1;
seg != NULL;
- seg = VG_(next_segment)(seg), i++) {
+ seg = VG_(next_segment)(seg)) {
if (!should_dump(seg))
continue;
- if (phdrs[i].p_filesz > 0) {
+ if (phdrs[idx].p_filesz > 0) {
Int ret;
- vg_assert(VG_(lseek)(core_fd, phdrs[i].p_offset, VKI_SEEK_SET) == phdrs[i].p_offset);
+ vg_assert(VG_(lseek)(core_fd, phdrs[idx].p_offset, VKI_SEEK_SET) == phdrs[idx].p_offset);
+ vg_assert(seg->len >= phdrs[idx].p_filesz);
- vg_assert(seg->len >= phdrs[i].p_filesz);
- ret = VG_(write)(core_fd, (void *)seg->addr, phdrs[i].p_filesz);
+ ret = VG_(write)(core_fd, (void *)seg->addr, phdrs[idx].p_filesz);
}
+ idx++;
}
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:31:53
|
CVS commit by fitzhardinge:
Take note of mmaps from devices, and avoid touching them casually.
Scanning one in the leak checker or trying to core-dump one could lock
up the machine.
M +2 -1 coregrind/core.h 1.91
M +13 -4 coregrind/vg_memory.c 1.92
M +2 -2 coregrind/vg_signals.c 1.131
M +1 -1 coregrind/vg_syscalls.c 1.254
M +20 -0 include/x86-linux/vki_arch.h 1.13
--- valgrind/coregrind/vg_syscalls.c #1.253:1.254
@@ -4188,5 +4188,5 @@ POST(sys_ioctl)
/* ioctls may spontaneously create memory mappings, so go
search for them */
- VG_(sync_segments)();
+ VG_(sync_segments)(SF_DEVICE | SF_MMAP);
}
break;
--- valgrind/coregrind/vg_memory.c #1.91:1.92
@@ -465,4 +465,8 @@ void VG_(map_fd_segment)(Addr addr, Size
if (VG_(fstat)(fd, &st) < 0)
flags &= ~SF_FILE;
+ else {
+ if (VKI_S_ISCHR(st.st_mode) || VKI_S_ISBLK(st.st_mode))
+ flags |= SF_DEVICE;
+ }
}
@@ -841,5 +845,5 @@ void VG_(find_root_memory)(void (*add_ro
for(s = VG_(first_segment)(); s != NULL; s = VG_(next_segment)(s)) {
- UInt flags = s->flags & (SF_SHARED|SF_MMAP|SF_VALGRIND|SF_CORE|SF_STACK);
+ UInt flags = s->flags & (SF_SHARED|SF_MMAP|SF_VALGRIND|SF_CORE|SF_STACK|SF_DEVICE);
if (flags != SF_MMAP && flags != SF_STACK)
continue;
@@ -978,4 +982,5 @@ void VG_(print_shadow_stats)()
static Segment *next_segment;
+static UInt sync_maps_flags;
static void sync_maps(Addr addr, SizeT len, UInt prot,
@@ -986,5 +991,7 @@ static void sync_maps(Addr addr, SizeT l
Addr end = addr+len;
Segment *seg, *first, *last;
- UInt flags = (addr < VG_(client_end)) ? 0 : SF_VALGRIND;
+ UInt flags = sync_maps_flags;
+
+ flags |= (addr < VG_(client_end)) ? 0 : SF_VALGRIND;
seg = next_segment;
@@ -1012,5 +1019,5 @@ static void sync_maps(Addr addr, SizeT l
if (debug)
VG_(printf)("SYNC: inserting %p-%p %s\n", addr, end, VG_(prot_str)(prot));
- VG_(map_file_segment)(addr, len, prot, flags | SF_MMAP, dev, ino, foff, filename);
+ VG_(map_file_segment)(addr, len, prot, flags, dev, ino, foff, filename);
VG_TRACK ( new_mem_mmap, addr, len,
@@ -1042,5 +1049,5 @@ static void sync_maps(Addr addr, SizeT l
}
-void VG_(sync_segments)(void)
+void VG_(sync_segments)(UInt flags)
{
static const Bool debug = 0;
@@ -1049,4 +1056,6 @@ void VG_(sync_segments)(void)
next_segment = VG_(first_segment)();
+ sync_maps_flags = flags;
+
VG_(parse_procselfmaps)(sync_maps);
--- valgrind/coregrind/core.h #1.90:1.91
@@ -1201,4 +1201,5 @@ extern void VG_(print_scheduler_stats) (
#define SF_VALGRIND (1 << 13) // a valgrind-internal mapping - not in client
#define SF_CODE (1 << 14) // segment contains cached code
+#define SF_DEVICE (1 << 15) // device mapping; avoid careless touching
struct _Segment {
@@ -1258,5 +1259,5 @@ extern REGPARM(1)
/* Search /proc/self/maps for changes which aren't reflected in the
segment list */
-extern void VG_(sync_segments)();
+extern void VG_(sync_segments)(UInt flags);
/* Check vg_memory structures for sanity */
--- valgrind/coregrind/vg_signals.c #1.130:1.131
@@ -911,5 +911,5 @@ void VG_(kill_self)(Int sigNo)
static Bool may_dump(const Segment *seg)
{
- return (seg->flags & SF_VALGRIND) == 0 && VG_(is_client_addr)(seg->addr);
+ return (seg->flags & (SF_DEVICE|SF_VALGRIND)) == 0 && VG_(is_client_addr)(seg->addr);
}
@@ -1762,5 +1762,5 @@ void vg_sync_signalhandler ( Int sigNo,
VG_(deliver_signal)(tid, info);
VG_(resume_scheduler)(tid);
- exit(99); /* If we can't resume, then just exit */
+ VG_(exit)(99); /* If we can't resume, then just exit */
}
--- valgrind/include/x86-linux/vki_arch.h #1.12:1.13
@@ -326,4 +326,24 @@ struct vki_sigcontext {
//----------------------------------------------------------------------
+#define VKI_S_IFMT 00170000
+#define VKI_S_IFSOCK 0140000
+#define VKI_S_IFLNK 0120000
+#define VKI_S_IFREG 0100000
+#define VKI_S_IFBLK 0060000
+#define VKI_S_IFDIR 0040000
+#define VKI_S_IFCHR 0020000
+#define VKI_S_IFIFO 0010000
+#define VKI_S_ISUID 0004000
+#define VKI_S_ISGID 0002000
+#define VKI_S_ISVTX 0001000
+
+#define VKI_S_ISLNK(m) (((m) & VKI_S_IFMT) == VKI_S_IFLNK)
+#define VKI_S_ISREG(m) (((m) & VKI_S_IFMT) == VKI_S_IFREG)
+#define VKI_S_ISDIR(m) (((m) & VKI_S_IFMT) == VKI_S_IFDIR)
+#define VKI_S_ISCHR(m) (((m) & VKI_S_IFMT) == VKI_S_IFCHR)
+#define VKI_S_ISBLK(m) (((m) & VKI_S_IFMT) == VKI_S_IFBLK)
+#define VKI_S_ISFIFO(m) (((m) & VKI_S_IFMT) == VKI_S_IFIFO)
+#define VKI_S_ISSOCK(m) (((m) & VKI_S_IFMT) == VKI_S_IFSOCK)
+
struct vki_stat {
unsigned long st_dev;
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:24:17
|
Nicholas Nethercote wrote:
> On Thu, 24 Feb 2005, Jeremy Fitzhardinge wrote:
>
>> ==18124== 128+4014 bytes in 1 blocks are definitely lost in loss
>> record 461 of 483
>
>
> It's good that the new reported sizes are more accurate, but I predict
> one thousand users will immediately scream "what does 128+4014 mean?"
> It's not at all obvious. Is there any simpler/more intuitive way to
> summarise, perhaps by changing the wording of the sentence?
I already changed it to
4142 (128+4014) bytes in 1 blocks are definitely lost in loss record 461 of 483
I suppose that could be
4142 (128 direct, 4014 indirect) bytes in 1 blocks are definitely lost in loss record 461 of 483
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-25 05:15:35
|
Nicholas Nethercote wrote:
>>
>> * big-bang shadow allocation causes problems on kernels that don't
>> do overcommitment
>>
>> * a fixed partitioning scheme is less appropriate if we move towards
>> compressed representations of shadow memory, since that compression
>> ratio could be variable
>
>
> Plus all the other problems mentioned in bug #82301, which we've
> talked about at length multiple times in the past.
The only additional problem in that bug is the difficulty with loading
large symbol files, which won't be helped by the superblock scheme at
all; it will be made worse. But that's OK, because the symtab reader
needs to be fixed anyway.
J
|
|
From: Tom H. <to...@co...> - 2005-02-25 03:28:49
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-25 03:20:04 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 ---------------------------------------- == 214 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-25 03:23:06
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-25 03:15:03 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 ---------------------------------------- == 213 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 |