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
|
2
|
|
3
|
4
|
5
|
6
|
7
(1) |
8
|
9
|
|
10
|
11
|
12
(6) |
13
(4) |
14
(3) |
15
(1) |
16
(2) |
|
17
(7) |
18
(1) |
19
(5) |
20
(3) |
21
(1) |
22
(5) |
23
|
|
24
(1) |
25
(3) |
26
(2) |
27
(1) |
28
(2) |
29
(1) |
30
|
|
31
|
|
|
|
|
|
|
|
From: <sv...@va...> - 2016-01-14 20:23:19
|
Author: philippe
Date: Thu Jan 14 20:23:11 2016
New Revision: 15759
Log:
fix n-i-bz false positive leaks due to aspacemgr merging non heap segments with heap segments.
aspace mgr provides VG_(am_mmap_client_heap) that mmaps memory and
marks it as being client heap memory. Marking superblock segments used
for malloc/free as heap is critical for correct leak search: segments
mmap-ed for malloc/free cannot be considered as part of the root set.
On the other hand, other mmap-ed segments cannot be marked as client
heap, otherwise these segments will not be part of the root set, and
will not be scanned.
aspacemgr merges adjacent segments when they have the same characteristics
e.g. kind, RWX and isCH (is client heap) must be the same (see function
maybe_merge_nsegments).
However, VG_(am_mmap_client_heap) has a bug:
* it first mmaps a normal segment (not marked as heap) using
VG_(am_mmap_anon_float_client)
* it then searches the segment that contains the just mmap-ed address and
marks it as heap.
The problem is that VG_(am_mmap_anon_float_client) has already
possibly merged the new segment with a neighbour segment, without
taking the to be marked isCH into account, as the newly allocated memory
has not yet been marked as Client Heap. So, this results in some memory being
marked as client heap, while it in fact is not client heap. This
memory will then not be scanned by the leak search.
The fix consists in having VG_(am_mmap_anon_float_client) and
VG_(am_mmap_client_heap) calling a new function
am_mmap_anon_float_client, which will mark (or not) the new segment as
client heap *before* trying to merge it with neighbouring segments.
Then the new (heap) segment will only be merged with neighbours that are also
client heap segments.
Modified:
trunk/NEWS
trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
trunk/coregrind/pub_core_aspacemgr.h
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Thu Jan 14 20:23:11 2016
@@ -62,6 +62,7 @@
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
+n-i-bz false positive leaks due to aspacemgr merging non heap segments with heap segments.
Release 3.11.0 (22 September 2015)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
==============================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-linux.c (original)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-linux.c Thu Jan 14 20:23:11 2016
@@ -2476,7 +2476,7 @@
/* Map anonymously at an unconstrained address for the client, and
update the segment array accordingly. */
-SysRes VG_(am_mmap_anon_float_client) ( SizeT length, Int prot )
+static SysRes am_mmap_anon_float_client ( SizeT length, Int prot, Bool isCH )
{
SysRes sres;
NSegment seg;
@@ -2524,12 +2524,17 @@
seg.hasR = toBool(prot & VKI_PROT_READ);
seg.hasW = toBool(prot & VKI_PROT_WRITE);
seg.hasX = toBool(prot & VKI_PROT_EXEC);
+ seg.isCH = isCH;
add_segment( &seg );
AM_SANITY_CHECK;
return sres;
}
+SysRes VG_(am_mmap_anon_float_client) ( SizeT length, Int prot )
+{
+ return am_mmap_anon_float_client (length, prot, False /* isCH */);
+}
/* Map anonymously at an unconstrained address for V, and update the
segment array accordingly. This is fundamentally how V allocates
@@ -2738,21 +2743,13 @@
fd, offset );
}
-/* Convenience wrapper around VG_(am_mmap_anon_float_client) which also
+/* Similar to VG_(am_mmap_anon_float_client) but also
marks the segment as containing the client heap. This is for the benefit
of the leak checker which needs to be able to identify such segments
so as not to use them as sources of roots during leak checks. */
SysRes VG_(am_mmap_client_heap) ( SizeT length, Int prot )
{
- SysRes res = VG_(am_mmap_anon_float_client)(length, prot);
-
- if (! sr_isError(res)) {
- Addr addr = sr_Res(res);
- Int ix = find_nsegment_idx(addr);
-
- nsegments[ix].isCH = True;
- }
- return res;
+ return am_mmap_anon_float_client (length, prot, True /* isCH */);
}
/* --- --- munmap helper --- --- */
Modified: trunk/coregrind/pub_core_aspacemgr.h
==============================================================================
--- trunk/coregrind/pub_core_aspacemgr.h (original)
+++ trunk/coregrind/pub_core_aspacemgr.h Thu Jan 14 20:23:11 2016
@@ -254,7 +254,7 @@
extern SysRes VG_(am_shared_mmap_file_float_valgrind)
( SizeT length, UInt prot, Int fd, Off64T offset );
-/* Convenience wrapper around VG_(am_mmap_anon_float_client) which also
+/* Similar to VG_(am_mmap_anon_float_client) but also
marks the segment as containing the client heap. */
extern SysRes VG_(am_mmap_client_heap) ( SizeT length, Int prot );
|
|
From: Carl E. L. <ce...@us...> - 2016-01-14 17:18:41
|
Valgrind developers:
I am working on support for the new Power instructions. There are some
instructions that access the 64 128-bit Vector Scalar Register (VSR)
file that I can't emulate with existing Valgrind Iops. So, I need to
add a new Iop for these instructions. The issue is that currently the
Power support in Valgrind only handles issuing instructions that access
the general purpose registers, the 32 64-bit floating point (FPR)
registers and the 32 128-bit Vector Registers (VR). Note, the hardware
actually maps the FPRs and VRs into subsets of the 64 VSR registers.
I am trying to figure out within Valgrind how the contents of a register
in the guest state is "copied" into the physical register on the target
register before executing the native instruction. Similarly, how the
contents of the physical register gets "copied" back to the guest state.
I understand the details on Power of generating a native instruction to
be executed, it is done in emit_PPCInstr (), host_ppc_defs.c. I think I
understand the code for the register allocater that selects a register
in Power register space. But I can't find where/how the contents of the
Power Guest register gets put into the a physical register before
executing the generated Power instruction.
I was expecting to see something within VEX that would generate native
loads of the arguments from the Guest register file into the host
registers, then the generated instruction followed by the generation of
a native store instruction from the register into the Guest register
file. I don't see any native load/store instructions to handle the
operands.
The other possibility is that the values for the registers is stored
along with the generated instructions in VEX but then in coregrind the
native instructions would be generated to load the registers and execute
the generated instruction for the Iop. I haven't found anything like
that either.
I am not sure where in Valgrind the generated native instructions are
actually issued. Anyway, if someone can outline how all this works and
where some of these things occur it would be a big help so I can figure
out the specifics on Power of extending support to native instructions
that use the VSRs. Thanks for your time.
Carl Love
|
|
From: Florian K. <fl...@ei...> - 2016-01-14 09:19:37
|
On 13.01.2016 10:50, Matthias Schwarzott wrote:
> Am 13.01.2016 um 08:18 schrieb Florian Krohm:
>> Given that we already have some support for MSC_VER in valgrind.h it
>> would be good to sort this out. But that file is already quite messy
>> with all the ifdeffery that is going on in there so we should be careful
>> adding more..
>>
> The attached patch is a draft version of a different way to cleanup
> VALGRIND_PRINTF.
>
Thanks for the patch.
Simplifying that file is a good thing. But I'd like to understand
whether we can get rid of some of the special casing.
__inline:
I presume this is needed to keep MSC_VER from complaining that the
function is possibly unused. Right?
uintptr_t:
I do not unerstand why this type is needed and we cannot use unsigned
long instead. svn archeology did not reveal anything except that Bart
might know.
Your #define __VALGRIND_PRINTF_ARGLIST ... will cause warnings with
most compilers because C does not allow such parameter lists.
To suppress the warning about the unused parameter we could use:
Index: include/valgrind.h
===================================================================
--- include/valgrind.h (revision 15754)
+++ include/valgrind.h (working copy)
@@ -6759,6 +6759,7 @@
VALGRIND_PRINTF(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
@@ -6797,6 +6798,7 @@
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
Florian
|