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
(5) |
2
(5) |
3
(17) |
4
(21) |
5
(24) |
6
(14) |
7
(14) |
|
8
(14) |
9
(18) |
10
(13) |
11
(15) |
12
(12) |
13
(4) |
14
(11) |
|
15
(10) |
16
(6) |
17
(14) |
18
(16) |
19
(10) |
20
(3) |
21
(12) |
|
22
(12) |
23
(11) |
24
(19) |
25
(15) |
26
(14) |
27
(16) |
28
(12) |
|
From: <sv...@va...> - 2015-02-02 22:41:02
|
Author: philippe
Date: Mon Feb 2 22:40:54 2015
New Revision: 14899
Log:
PTRACE_GETREGS might not be detected on some distro, due to a missing #include
in the configure test.
Modified:
trunk/configure.ac
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Mon Feb 2 22:40:54 2015
@@ -1084,6 +1084,7 @@
AC_MSG_CHECKING([for PTRACE_GETREGS])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#include <stdlib.h>
#include <stddef.h>
#include <sys/ptrace.h>
#include <sys/user.h>
|
|
From: Philippe W. <phi...@sk...> - 2015-02-02 21:41:13
|
On Mon, 2015-02-02 at 07:51 +0100, Matthias Schwarzott wrote: > Hi! > > Just out of interest: Is the new x32 ABI for amd64 already supported in > valgrind? From looking at the source-code I would guess not. No, it is not supported. > > What would be necessary to support this? Good question, not clear to me. > > Ideas: > * Support the missing syscalls. Is there a lot of x32 specific syscalls ? Or is it needed to rewrite all/a lot of the wrappers ? What about VEX lib, which I guess might be impacted a lot ? > * Support for more "secondary" archs (Makefile cleanup) Wondering if we shouldn't drop the idea of having primary and secondary platforms, and just have a kind of 'top' configure/make that would be called once per arch. That might be simpler than having a primary, secondary and tertiary approach. At least, at my work, for strange reasons, we have to use 2 different compilers for 32 bits and 64 bits. The easiest was just to have a configure/make with one compiler, and then with the other compiler in another directory, and have make install called twice (thereby adding files, or replacing files). The only thing to pay attention to is that some programs (e.g. valgrind, vgdb, ...) have to be 'multi-arch', i.e. support whatever is necessary, and that the 'richer' arch is to be installed latest. (richer = e.g. the vgdb 64 bit version, that can work with both 32 bits and 64 bits 'clients'). At least initially, adding a new primary arch x32 might be already a gigantic first step, the concept of tertiary platform can for sure be done later :). > * A valgrind-loader for x32 You mean the 'normal' executable that launches the tool. This one is pretty independent of the arch, to my knowledge. > * Making 32bit vs. 64bit memory management depend on ABI and not on cpu > architecture. Not clear what you mean here. For sure, assuming x32 starts to be used significantly, adding x32 support will be a nice thing to have. (note however that I saw no request/demand up to now). Philippe |
|
From: Florian K. <fl...@ei...> - 2015-02-02 18:16:42
|
Consider this snippet from m_addrinfo.c:
const NSegment *seg = VG_(am_find_nsegment) (a);
...
if (seg->kind == SkFileC)
ai->Addr.SegmentKind.filename
= VG_(strdup)("mc.da.skfname", VG_(am_get_filename)(seg));
ai->Addr.SegmentKind.hasR = seg->hasR;
ai->Addr.SegmentKind.hasW = seg->hasW;
ai->Addr.SegmentKind.hasX = seg->hasX;
There is nothing wrong here. It is clear, though, that the code
assumes that strdup does not modify the memory pointed to by 'seg'.
But that is not necessarily true. The problem occurs when there is
no memory available to store the string. In that case we may get the
following call chain:
- strdup
- arena_malloc
- newSuperblock
- am_mmap_anon_float_valgrind
- add_segment
- split_nsegments_lo_and_hi
- split_nsegment_at
The last function in this chain may do this:
for (j = nsegments_used-1; j > i; j--)
nsegments[j+1] = nsegments[j];
So... with 'seg' being a pointer into the nsegments array it means that
after the strdup the contents of the memory pointed to by seg
may have been changed by above loop.
Not so good.
The pointers to NSegment we return and deal with in the various
externally visible aspacemgr functions cannot be pointers into the
sorted array of nsegments if its contents gets moved around.
I'm currently thinking of adding
NSegment *sorted_nsegments[VG_N_SEGMENTS]
as a fix. Basically, introducing another level of indirection. But I
haven't given it too much thought yet and an open for ideas.
I won't be getting to fixing this until sometime next week.
Florian
|
|
From: Florian K. <fl...@ei...> - 2015-02-02 17:21:53
|
On 31.01.2015 01:29, sv...@va... wrote:
>
> For a segment name to become unused there must be an assignment to
> NSegment::fnIdx which was previously assigned a return value from
> allocate_segname.
Yes.
> There is no such assignment.
Wrong. I missed this assignment (in pass #2 of preen_segments):
nsegments[w] = nsegments[r];
This happens when two named segments can be merged. One would expect (at
least I would) that only named segments with the same name can be merged
but that is not the case. See thread entitled "a question about
maybe_merge_segments" of Nov 11, 2014.
So with r14898 we could have an occasional segment name leak. I did a
few experiments. No named segments were merged (I have never see that
happen).
#segments #segnames SegName size string table size
abiword 1175 290 290580 14203
vlc 960 665 666330 33171
avidemux 1049 243 243486 12338
All sizes in bytes.
The SegName size is sizeof(SegName) * #segment names.
For all experiments the savings is approx 95%
That looks like significant enough improvement to me to allow an
occasional, if any, leak of a segment name.
Florian
|
|
From: Matthias S. <zz...@ge...> - 2015-02-02 06:51:24
|
Hi! Just out of interest: Is the new x32 ABI for amd64 already supported in valgrind? From looking at the source-code I would guess not. What would be necessary to support this? Ideas: * Support the missing syscalls. * Support for more "secondary" archs (Makefile cleanup) * A valgrind-loader for x32 * Making 32bit vs. 64bit memory management depend on ABI and not on cpu architecture. Regards Matthias |