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: Bryan O'S. <bo...@se...> - 2005-02-23 23:52:08
|
On Wed, 2005-02-23 at 23:03 +0000, Julian Seward wrote: > This is an amd64-linux issue. It seems that at least some > AMD64 distros (SuSE) are built using a "small model" where > offsets in literal jumps are signed 32-bits and so that appears > to force all code below 2 G. Everyone uses the small code model on x86_64. At least some parts of the tool chain (don't remember whether it was gcc or binutils) don't even support the medium or large code models. > What object file format does MacOSX use? ELF? How lucky are we? The object file format is Mach-O, and the debug format is stabs. http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime <b |
|
From: Julian S. <js...@ac...> - 2005-02-23 23:04:40
|
Greg
> Note that "complete control" cannot be totally complete in a
> Mach environment.
> [...]
> When Valgrind goes to allocate new non-client memory, it would
> first uses vm_allocate to claim an entire superblock-size region,
> and only then carve up the space inside.
This is useful stuff. Thanks.
What I plan to do is build an abstraction layer for messing with
the underlying OS -- sort-of an enhanced and cleaned up vg_mylibc.c,
so that V proper is insulated as much as possible from these
kinds of details. It's long overdue. With a bit of care it sounds
like it's possible to design the boundary so that MacOSX can be
plugged in underneath it too.
> > That's not wonderful, but even a 1 Mb static area should hold
> > enough info to track several thousand segments.
>
> How many thousand? Big Mac OS X apps already routinely use a few
> thousand VM blocks in client space, though this would probably be
> smaller after Valgrind's coalescing.
Well, let's say a block descriptor involves { a start address,
a length, a word containing flags, an int index into a filename
table, and perhaps a couple more words to make administration
a bit faster }. That's 40ish bytes. That gives 25k descriptors
per megabyte. How many do you need? Even if you need 200k
descriptors I don't care if we have to statically allocate 8M
to make that work. The only real issue is ensuring that update/
query operations on the map don't get too slow due to a compact
representation.
> > * At least for Linux, stage2 is loaded into a 64M superblock
> > just below 0x4000'0000 (1 G). ASpaceMgr allocates superblocks
> > on demand, above 1G if it can for shadow memory and for Valgrind's
> > own use, and below 1G for the client, if possible. In particular
> > it tries hard not to put Valgrind or Shadow data in the area
> > below 1G.
>
> This is all flexible, right?
Yes, definitely. I'm aiming for something which (1) is flexible
and (2) clearly separates policy from implementation.
> Mac OS X has some entertaining address space requirements and
> restrictions.
Can you summarise what they are, so I can muse on the consequences
thereof?
> > - On a 64-bit machine, all code is to be mapped in below 1 G, but
> > apart from that ASpaceMgr can be fairly relaxed about fragmentation
> > in the area above 1 G.
>
> Where does the "all code below 1G" requirement come from? Is that
> particular to the codegen in 64-bit Linux? Does Valgrind need it
> for some reason? Is it just a preference?
This is an amd64-linux issue. It seems that at least some
AMD64 distros (SuSE) are built using a "small model" where
offsets in literal jumps are signed 32-bits and so that appears
to force all code below 2 G. Or at least into some contiguous
2 G range.
I must admit I don't exactly understand the issues for layout and
code models on amd64. Can any amd64-linux junkies clarify this?
DirkM?
> > (3) Use a standalone ELF .o loader/linker to load all the .o's,
> > link and start them.
> >
> > At first (3) sounds insane, but it has a couple of advantages:
>
> It's not that insane. I wrote a system that does something
> similar for Palm OS, to get around its restrictions on code
> size and global variables. A full-blown ELF .o linker was
> overkill for me;
Well, the work is already done - here's one I made earlier:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Linker.c
It works for ELF on x86, amd64, ppc32, used to work for arm,
looks like it can be made to work for ia64, and (at least at
some point in the past) could also load/link Windows PEi386
object files :-) It's a modular linker and so can be extended
to new formats (eg COFF) by writing the appropriate COFF-parsers.
> My Mac OS X launcher has this problem. gdb can see Valgrind's
> symbols, but can't set any breakpoints, and is easily confused
> about other things. gdb knows nothing about the client or its
> libraries. It's all rather clumsy to work with, but not the
> end of the world.
Not good tho; if V crashes we really want GDB to be able to say
what's going on.
What object file format does MacOSX use? ELF? How lucky are we?
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-23 20:37:46
|
On Wed, 23 Feb 2005, Jeremy Fitzhardinge wrote: > A more general comment is that I'd really like to come up with a way of > dealing with ioctls which doesn't require adding more stuff into > vg_unsafe.h, and doesn't require duplicating structures into vki*.h. What version was the patch against? vg_unsafe.h doesn't exist in the CVS HEAD any more. N |
|
From: Greg P. <gp...@us...> - 2005-02-23 19:21:21
|
Julian Seward writes: > * I found the code hard to understand (== maintain) and there is > no comprehensive statement of what it is and is not trying to > achieve. Agreed. I have memory map tracking mostly working on Mac OS X, but there are plenty of gaps in my knowledge. (For example, what do all of the SF_xxx flags really mean, and how do they apply to Darwin's memory usage?) > Since we have chosen not to virtualise the client's address space, > we have to share it. And since the client doesn't know we're there, > we have to take complete control of the address space. That much > is implemented, and it's a good idea. Note that "complete control" cannot be totally complete in a Mach environment. On Mac OS X, the kernel and other processes can insert memory regions into the client with little or no warning and no control over the destination. Existing memory regions will not be clobbered, but everything else is fair game. The Window Server in particular does this all the time, so Valgrind needs to handle this in order to be useful. One problem that results is that Valgrind must not unilaterally use mmap(MAP_FIXED) on memory that it thinks is unoccupied. The kernel could be simultaneously inserting its own mapping there, and mmap(MAP_FIXED) always clobbers whatever was there previously. The solution is probably judicious use of Mach's vm_allocate(), which will refuse to clobber existing regions, even if you demand a MAP_FIXED-style absolute address. The flexibility of a superblock system would also help greatly. When Valgrind goes to allocate new non-client memory, it would first uses vm_allocate to claim an entire superblock-size region, and only then carve up the space inside. Non-client mmap(MAP_FIXED) would always be preceded by vm_allocate() of the space underneath. Client mmap(MAP_FIXED) would need to be check to make sure it did not overlap with a non-client superblock, but otherwise would go unchanged. (If the client unexpectedly clobbers its own memory with mmap(MAP_FIXED), it's their problem.) > * As mentioned above, the Address Space Manager is fundamental > and self-contained. It is decoupled from the malloc/free manager. > It no longer deals with debug info loading/unloading. It does > nothing that requires dynamic memory allocation. The segment list > is to be held in statically allocated storage to make that possible. > That's not wonderful, but even a 1 Mb static area should hold > enough info to track several thousand segments. How many thousand? Big Mac OS X apps already routinely use a few thousand VM blocks in client space, though this would probably be smaller after Valgrind's coalescing. > * At least for Linux, stage2 is loaded into a 64M superblock > just below 0x4000'0000 (1 G). ASpaceMgr allocates superblocks > on demand, above 1G if it can for shadow memory and for Valgrind's > own use, and below 1G for the client, if possible. In particular > it tries hard not to put Valgrind or Shadow data in the area > below 1G. This is all flexible, right? Mac OS X has some entertaining address space requirements and restrictions. But a superblock system does work better than a single "client here, Valgrind there" line. > - On a 64-bit machine, all code is to be mapped in below 1 G, but > apart from that ASpaceMgr can be fairly relaxed about fragmentation > in the area above 1 G. Where does the "all code below 1G" requirement come from? Is that particular to the codegen in 64-bit Linux? Does Valgrind need it for some reason? Is it just a preference? > (3) Use a standalone ELF .o loader/linker to load all the .o's, > link and start them. > > At first (3) sounds insane, but it has a couple of advantages: It's not that insane. I wrote a system that does something similar for Palm OS, to get around its restrictions on code size and global variables. A full-blown ELF .o linker was overkill for me; instead I linked everything with --emit-relocs, and then re-relocated everything at runtime using a custom loader. There are far fewer relocation types that need to be handled at this point, and the static linker has already done all of the memory layout and most symbol resolution. > The main disadvantage is that gdb would not have a clue what it > was looking at unless we found a way to convey debug info to it. My Mac OS X launcher has this problem. gdb can see Valgrind's symbols, but can't set any breakpoints, and is easily confused about other things. gdb knows nothing about the client or its libraries. It's all rather clumsy to work with, but not the end of the world. -- Greg Parker gp...@us... |
|
From: Tyler N. <tyl...@co...> - 2005-02-23 18:23:44
|
On Wed, 2005-02-23 at 08:20 -0800, Jeremy Fitzhardinge wrote: > Tyler Nielsen wrote: > > >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. > > > No, this definitely isn't correct. Not threadsafe for one thing. What > is the URB pointer state associated with? The file descriptor? An > underlying device? > > A more general comment is that I'd really like to come up with a way of > dealing with ioctls which doesn't require adding more stuff into > vg_unsafe.h, and doesn't require duplicating structures into vki*.h. > J btw. It does look wrong to me, I just couldn't find the 'right' way. I assume that it is tied to the file descriptor, but I can't find any documentation that explicitly says that. There is a option to set a user pointer to some context (that is how you identify which urb completed). Perhaps a better way to do this would be to have valgrind modify this user pointer before the first ioctl, and undo the modification after the second ioctl. This should be 100% correct behavior, but would require either a malloc/free or some allocated space, and I didn't really see that happening anywhere in vg_syscalls.c. -- Tyler Nielsen <tyl...@co...> |
|
From: Julian S. <js...@ac...> - 2005-02-23 18:12:36
|
Recently I had to futz with low-level memory management to get
programs started on AMD64. As it turned out my problems were
self-inflicted, but as a side-effect I trogged around the
segment-tracking/address-space-management stuff in great detail.
Since we have chosen not to virtualise the client's address space,
we have to share it. And since the client doesn't know we're there,
we have to take complete control of the address space. That much
is implemented, and it's a good idea.
There are, however, aspects of the implementation that concern me:
* There's a fundamental circularity which has caused segfaults
at least twice in the past. The segment list manager needs
the malloc/free manager to be operating, but the malloc/free
manager may cause segment list entries to be allocated.
In effect we have two competing low level memory managers,
a situation which is nonsensical and should be fixed. The
segment-list-manager (which we should really call the
Address Space Manager, ASpaceMgr) is fundamental and should be
self-contained. The malloc/free manager should be built on
top of ASpaceMgr. The point at which debug info reading is
done should be moved upwards in the services hierarchy
to enable this split to be made.
* Abstraction boundaries in vg_mylibc have been muddied. Once
upon a time, VG_(mmap) and VG_(mprotect) simply passed requests
through to the kernel. Now they are part of the segment-mapping
game and make enquiries against the segment list. That functionality
needs to exist somewhere, but it's confusing that it happens
at that low a level.
* I found the code hard to understand (== maintain) and there is
no comprehensive statement of what it is and is not trying to
achieve.
I've also been considering how to rework address space management to
support a 64-bit world. The following proposal builds on my proposal
of a couple of weeks ago, which proposed chopping the address space
up into 64M chunks and doing permissions checks at that granularity.
* The 64M superblocks have 4 possible ownership states:
Unallocated
Valgrind's -- V's text, stack, static data, dynamic data
Shadow
Client
* As mentioned above, the Address Space Manager is fundamental
and self-contained. It is decoupled from the malloc/free manager.
It no longer deals with debug info loading/unloading. It does
nothing that requires dynamic memory allocation. The segment list
is to be held in statically allocated storage to make that possible.
That's not wonderful, but even a 1 Mb static area should hold
enough info to track several thousand segments.
* At least for Linux, stage2 is loaded into a 64M superblock
just below 0x4000'0000 (1 G). ASpaceMgr allocates superblocks
on demand, above 1G if it can for shadow memory and for Valgrind's
own use, and below 1G for the client, if possible. In particular
it tries hard not to put Valgrind or Shadow data in the area
below 1G.
Why 0x4000'0000 ?
- On a 32-bit machine, this gives the client nearly 1G of
contiguous space, should it want to do large mmaps. If
clients want to mmap more than 1G at a time, that's tough
-- use 64-bit Valgrind instead.
- On a 32-bit machine, even if the top 3/4 of the address space
is given over to the kernel, we don't have to deal with
different load addresses -- it will work as-is. Under those
conditions ASpaceMgr will have to make inroads into the top
of the 1G area, but that's unavoidable.
- In general, on a 32-bit machine, because memory is allocated
in 64M superblocks to either shadow, client or V-internal, we get
rid of all problems associated with the current hard partitioning
scheme between client and shadow memory. Big-bang allocation is
done away with. We know we can still protect V from wild writes
by the client at fairly minimal expense.
- On a 64-bit machine, all code is to be mapped in below 1 G, but
apart from that ASpaceMgr can be fairly relaxed about fragmentation
in the area above 1 G.
Startup then looks like this:
* Load stage2 at 0x4000'0000 - 64M
* Copy command-line/env data into this area somewhere
* Switch stacks and start stage2
* stage2: initialise ASpaceMgr, read initial segments from
/proc/self/maps
* Initialise logging, so we can print debugging info
early on. Note this means the logging mechanism cannot
do dynamic memory allocation.
* Nuke all segments except this one -- this gets the address
space in a known starting state
* Initialise the malloc/free manager
* Initialise scheduler
* Get signals in a known state; initialise signals subsystem
* Initialise any other subsystems (Vex?)
* Make the ume mechanism load the client
* Run the client
The only part of any difficulty is to get stage2 to a specific
address. Three possibilities:
(1) Link it to load at that address at build-time.
(2) Build it as a PIE.
(3) Use a standalone ELF .o loader/linker to load all the .o's,
link and start them.
At first (3) sounds insane, but it has a couple of advantages:
- we don't need to screw around padding the space with mmap in
stage1 to ensure stage2 and all its bits & pieces end up in
the designated 64 M superblock
- it gives us 100% control over V's linking and makes it easy to
ensure we don't inadvertantly depend on anything from glibc.
I like that.
The main disadvantage is that gdb would not have a clue what it
was looking at unless we found a way to convey debug info to it.
Congratulations to anybody who made it this far. Comments?
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-23 16:20:57
|
Tyler Nielsen wrote:
>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.
>
No, this definitely isn't correct. Not threadsafe for one thing. What
is the URB pointer state associated with? The file descriptor? An
underlying device?
A more general comment is that I'd really like to come up with a way of
dealing with ioctls which doesn't require adding more stuff into
vg_unsafe.h, and doesn't require duplicating structures into vki*.h.
J
|
|
From: Tom H. <th...@cy...> - 2005-02-23 08:35:30
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-23 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: Tom H. <th...@cy...> - 2005-02-23 08:35:18
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-02-23 03:05:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in cachegrind/tests/x86 ------------------------------ -- Finished tests in cachegrind/tests ---------------------------------- -- Running tests in corecheck/tests ----------------------------------- 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 Could not read `pth_cancel2.stderr.exp' make: *** [regtest] Error 2 |
|
From: Tom H. <th...@cy...> - 2005-02-23 08:35:09
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-23 03:00: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: Jeremy F. <je...@go...> - 2005-02-23 07:17:36
|
CVS commit by fitzhardinge:
Report lost siginfos a bit more idiomatically.
M +24 -8 vg_signals.c 1.130
--- valgrind/coregrind/vg_signals.c #1.129:1.130
@@ -1728,12 +1728,4 @@ void vg_sync_signalhandler ( Int sigNo,
Bool resume_sched = False;
- if (info->_sifields._kill._pid == 0) {
- VG_(message)(Vg_UserMsg, "Signal %d (%s) appears to have lost its siginfo; I can't go on.",
- sigNo, signame(sigNo));
- VG_(message)(Vg_UserMsg, " This may be because one of your programs has consumed your");
- VG_(message)(Vg_UserMsg, " ration of siginfo structures.");
- exit(99);
- }
-
if (VG_(threads)[tid].status == VgTs_WaitSys) {
/* This is like a normal async signal, but we can't simply
@@ -1749,4 +1741,28 @@ void vg_sync_signalhandler ( Int sigNo,
}
+ if (info->_sifields._kill._pid == 0) {
+ /* There's a per-user limit of pending siginfo signals. If
+ you exceed this, by having more than that number of
+ pending signals with siginfo, then new signals are
+ delivered without siginfo. This condition can be caused
+ by any unrelated program you're running at the same time
+ as Valgrind, if it has a large number of pending siginfo
+ signals which it isn't taking delivery of.
+
+ Since we depend on siginfo to work out why we were sent a
+ signal and what we should do about it, we really can't
+ continue unless we get it. */
+ VG_(message)(Vg_UserMsg, "Signal %d (%s) appears to have lost its siginfo; I can't go on.",
+ sigNo, signame(sigNo));
+ VG_(message)(Vg_UserMsg, " This may be because one of your programs has consumed your");
+ VG_(message)(Vg_UserMsg, " ration of siginfo structures.");
+
+ /* It's a fatal signal, so we force the default handler. */
+ VG_(set_default_handler)(sigNo);
+ VG_(deliver_signal)(tid, info);
+ VG_(resume_scheduler)(tid);
+ exit(99); /* If we can't resume, then just exit */
+ }
+
if (VG_(clo_trace_signals))
VG_(message)(Vg_DebugMsg, "Routing user-sent sync signal %d via queue; resume_sched=%d",
|
|
From: Tom H. <to...@co...> - 2005-02-23 03:30:37
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-23 03:20:07 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 ---------------------------------------- == 206 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-23 03:24:29
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-23 03:15:04 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 ---------------------------------------- == 205 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-23 02:33:34
|
CVS commit by fitzhardinge:
Make the leak-checker handle references to 0-byte allocations properly.
BUGS:99923
M +10 -5 mac_leakcheck.c 1.18
--- valgrind/memcheck/mac_leakcheck.c #1.17:1.18
@@ -201,5 +201,5 @@ Int find_shadow_for_OLD ( Addr pt
PROF_EVENT(71);
a_lo = shadows[i]->data;
- a_hi = ((Addr)shadows[i]->data) + shadows[i]->size - 1;
+ a_hi = ((Addr)shadows[i]->data) + shadows[i]->size;
if (a_lo <= ptr && ptr <= a_hi)
return i;
@@ -227,5 +227,5 @@ Int find_shadow_for ( Addr ptr,
mid = (lo + hi) / 2;
a_mid_lo = shadows[mid]->data;
- a_mid_hi = shadows[mid]->data + shadows[mid]->size - 1;
+ a_mid_hi = shadows[mid]->data + shadows[mid]->size;
if (ptr < a_mid_lo) {
@@ -277,16 +277,21 @@ void vg_detect_memory_leaks_notify_addr
line.
*/
- if (!VG_(is_client_addr)(a)) return;
+ if (!VG_(is_client_addr)(a))
+ return;
/* OK, let's get on and do something Useful for a change. */
ptr = (Addr)word_at_a;
+ if (0)
+ VG_(printf)("notify %p -> %x; min=%p max=%p\n", a, word_at_a,
+ lc_min_mallocd_addr, lc_max_mallocd_addr);
if (ptr >= lc_min_mallocd_addr && ptr <= lc_max_mallocd_addr) {
/* Might be legitimate; we'll have to investigate further. */
sh_no = find_shadow_for ( ptr, lc_shadows, lc_n_shadows );
+ if (0) VG_(printf)("find_shadow_for(%p) -> %d\n", ptr, sh_no);
if (sh_no != -1) {
/* Found a block at/into which ptr points. */
sk_assert(sh_no >= 0 && sh_no < lc_n_shadows);
- sk_assert(ptr < lc_shadows[sh_no]->data + lc_shadows[sh_no]->size);
+ sk_assert(ptr <= lc_shadows[sh_no]->data + lc_shadows[sh_no]->size);
/* Decide whether Proper-ly or Interior-ly reached. */
if (ptr == lc_shadows[sh_no]->data) {
@@ -391,5 +396,5 @@ void MAC_(do_detect_memory_leaks) (
lc_min_mallocd_addr = lc_shadows[0]->data;
lc_max_mallocd_addr = lc_shadows[lc_n_shadows-1]->data
- + lc_shadows[lc_n_shadows-1]->size - 1;
+ + lc_shadows[lc_n_shadows-1]->size;
lc_reachedness = VG_(malloc)( lc_n_shadows * sizeof(Reachedness) );
|
|
From: Jeremy F. <je...@go...> - 2005-02-23 02:22:36
|
CVS commit by fitzhardinge:
Don't loop infinitely if it looks like we've lost the siginfo from
a signal. If this happens, it generally means some other program has
consumed the user's full quota of siginfo structures, and Valgrind can't
live without them.
BUGS:99142
M +8 -0 vg_signals.c 1.129
--- valgrind/coregrind/vg_signals.c #1.128:1.129
@@ -1728,4 +1728,12 @@ void vg_sync_signalhandler ( Int sigNo,
Bool resume_sched = False;
+ if (info->_sifields._kill._pid == 0) {
+ VG_(message)(Vg_UserMsg, "Signal %d (%s) appears to have lost its siginfo; I can't go on.",
+ sigNo, signame(sigNo));
+ VG_(message)(Vg_UserMsg, " This may be because one of your programs has consumed your");
+ VG_(message)(Vg_UserMsg, " ration of siginfo structures.");
+ exit(99);
+ }
+
if (VG_(threads)[tid].status == VgTs_WaitSys) {
/* This is like a normal async signal, but we can't simply
|