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
(14) |
2
(16) |
3
(13) |
4
(3) |
|
5
(18) |
6
(1) |
7
(6) |
8
(2) |
9
(16) |
10
(19) |
11
(14) |
|
12
(1) |
13
(6) |
14
(20) |
15
(26) |
16
(18) |
17
(15) |
18
(16) |
|
19
(7) |
20
(8) |
21
(19) |
22
(19) |
23
(21) |
24
(15) |
25
(15) |
|
26
(11) |
27
(17) |
28
(21) |
29
(14) |
|
|
|
|
From: Philippe W. <phi...@sk...> - 2012-02-26 22:35:37
|
On Sun, 2012-02-26 at 15:39 -0500, Florian Krohm wrote: > On 02/26/2012 12:54 PM, Bart Van Assche wrote: > > Maybe it's a good idea to introduce a VEX_OFFSETOF() macro in order to > > improve readability of the above statement ? > > Would there be other uses for VEX_OFFSETOF elsewhere? Then it might be > worth doing. The whole thing is a bit ugly.... There are already so many uses of offset of that it is already defined :). See e.g. coregrind/m_translate.c various usage of 'offsetof'. Philippe |
|
From: Philippe W. <phi...@sk...> - 2012-02-26 21:58:43
|
On Sun, 2012-02-26 at 21:26 +0000, sv...@va... wrote: > Author: philippe > Date: 2012-02-26 21:26:00 +0000 (Sun, 26 Feb 2012) > New Revision: 12405 > > Log: > Fix some memory leaks found by running memcheck on annotated memcheck. Note that there is one reported leak I did not fix, as it is not easy to fix, and it is a one shot leak. ==11755== 392 bytes in 1 blocks are definitely lost in loss record 66 of 115 ==11755== at 0x2803A155: vgPlain_arena_malloc (m_mallocfree.c:1599) ==11755== by 0x2803A7CF: vgPlain_malloc (m_mallocfree.c:2125) ==11755== by 0x28073610: vgPlain_ii_create_image (initimg-linux.c:202) ==11755== by 0x280326DF: valgrind_main (m_main.c:1718) ==11755== by 0x28035E3C: _start_in_C_linux (m_main.c:2797) ==11755== by 0x28030A5B: ??? (in /home/philippe/valgrind/memcheck_inner_annot/install/lib/valgrind/memcheck-x86-linux) |
|
From: <sv...@va...> - 2012-02-26 21:30:34
|
Author: philippe
Date: 2012-02-26 21:26:00 +0000 (Sun, 26 Feb 2012)
New Revision: 12405
Log:
Fix some memory leaks found by running memcheck on annotated memcheck.
Modified:
trunk/coregrind/m_errormgr.c
trunk/memcheck/mc_leakcheck.c
Modified: trunk/coregrind/m_errormgr.c
===================================================================
--- trunk/coregrind/m_errormgr.c 2012-02-26 17:51:28 UTC (rev 12404)
+++ trunk/coregrind/m_errormgr.c 2012-02-26 21:26:00 UTC (rev 12405)
@@ -1103,26 +1103,30 @@
}
-/* *p_caller contains the raw name of a caller, supposedly either
+/* buf contains the raw name of a caller, supposedly either
fun:some_function_name or
- obj:some_object_name.
- Set *p_ty accordingly and advance *p_caller over the descriptor
- (fun: or obj:) part.
+ obj:some_object_name or
+ ...
+ Set p->ty and p->name accordingly.
+ p->name is allocated and set to the string
+ after the descriptor (fun: or obj:) part.
Returns False if failed.
*/
-static Bool setLocationTy ( SuppLoc* p )
+static Bool setLocationTy ( SuppLoc* p, Char *buf )
{
- if (VG_(strncmp)(p->name, "fun:", 4) == 0) {
- p->name += 4;
+ if (VG_(strncmp)(buf, "fun:", 4) == 0) {
+ p->name = VG_(arena_strdup)(VG_AR_CORE,
+ "errormgr.sLTy.1", buf+4);
p->ty = FunName;
return True;
}
- if (VG_(strncmp)(p->name, "obj:", 4) == 0) {
- p->name += 4;
+ if (VG_(strncmp)(buf, "obj:", 4) == 0) {
+ p->name = VG_(arena_strdup)(VG_AR_CORE,
+ "errormgr.sLTy.2", buf+4);
p->ty = ObjName;
return True;
}
- if (VG_(strcmp)(p->name, "...") == 0) {
+ if (VG_(strcmp)(buf, "...") == 0) {
p->name = NULL;
p->ty = DotDotDot;
return True;
@@ -1200,7 +1204,10 @@
supp->string = supp->extra = NULL;
eof = VG_(get_line) ( fd, &buf, &nBuf, &lineno );
- if (eof) break;
+ if (eof) {
+ VG_(arena_free)(VG_AR_CORE, supp);
+ break;
+ }
if (!VG_STREQ(buf, "{")) BOMB("expected '{' or end-of-file");
@@ -1253,6 +1260,8 @@
if (VG_STREQ(buf, "}"))
break;
}
+ VG_(arena_free)(VG_AR_CORE, supp->sname);
+ VG_(arena_free)(VG_AR_CORE, supp);
continue;
}
@@ -1280,9 +1289,7 @@
BOMB("too many callers in stack trace");
if (i > 0 && i >= VG_(clo_backtrace_size))
break;
- tmp_callers[i].name = VG_(arena_strdup)(VG_AR_CORE,
- "errormgr.losf.3", buf);
- if (!setLocationTy(&(tmp_callers[i])))
+ if (!setLocationTy(&(tmp_callers[i]), buf))
BOMB("location should be \"...\", or should start "
"with \"fun:\" or \"obj:\"");
i++;
Modified: trunk/memcheck/mc_leakcheck.c
===================================================================
--- trunk/memcheck/mc_leakcheck.c 2012-02-26 17:51:28 UTC (rev 12404)
+++ trunk/memcheck/mc_leakcheck.c 2012-02-26 21:26:00 UTC (rev 12405)
@@ -1276,6 +1276,7 @@
/*clique*/-1, /*cur_clique*/-1,
searched, szB);
}
+ VG_(free)(seg_starts);
}
/*------------------------------------------------------------*/
|
|
From: Florian K. <br...@ac...> - 2012-02-26 20:39:43
|
On 02/26/2012 12:54 PM, Bart Van Assche wrote: > On Sun, Feb 26, 2012 at 5:00 PM, <sv...@va...> wrote: > >> @@ -352,7 +370,7 @@ >> HChar* curr; >> HChar* next; >> Int ALIGN; >> - ALIGN = sizeof(void*)-1; >> + ALIGN = ((Int) ((UChar *)&s.x - (UChar *)&s)) - 1; >> nbytes = (nbytes + ALIGN) & ~ALIGN; >> curr = private_LibVEX_alloc_curr; >> next = curr + nbytes; >> > > Maybe it's a good idea to introduce a VEX_OFFSETOF() macro in order to > improve readability of the above statement ? Would there be other uses for VEX_OFFSETOF elsewhere? Then it might be worth doing. The whole thing is a bit ugly.... > An additional benefit is that > doing so would allow to remove the stack variable "s" again - at least if a > name would be assigned to the structure definition. > The compiler will throw out the variable as its value is not used. Florian |
|
From: Florian K. <br...@ac...> - 2012-02-26 20:37:07
|
On 02/26/2012 02:35 PM, Christian Borntraeger wrote:
>> + /* ... except SP, FPC, and IA */
>
> R14 seems also be defined. See ELF_PLAT_INIT.
>
Not according to the ABI document.
Florian
|
|
From: Christian B. <bor...@de...> - 2012-02-26 19:35:25
|
> + /* ... except SP, FPC, and IA */ R14 seems also be defined. See ELF_PLAT_INIT. |
|
From: <sv...@va...> - 2012-02-26 17:56:01
|
Author: florian
Date: 2012-02-26 17:51:28 +0000 (Sun, 26 Feb 2012)
New Revision: 12404
Log:
Tighten up initial guest/shodow state on s390x.
Modified:
trunk/coregrind/m_initimg/initimg-linux.c
trunk/coregrind/pub_core_machine.h
Modified: trunk/coregrind/m_initimg/initimg-linux.c
===================================================================
--- trunk/coregrind/m_initimg/initimg-linux.c 2012-02-26 17:01:22 UTC (rev 12403)
+++ trunk/coregrind/m_initimg/initimg-linux.c 2012-02-26 17:51:28 UTC (rev 12404)
@@ -1061,14 +1061,26 @@
is also done by the kernel for the fpc during execve. */
LibVEX_GuestS390X_initialise(&arch->vex);
- /* Zero out the shadow area. */
- VG_(memset)(&arch->vex_shadow1, 0, sizeof(VexGuestS390XState));
- VG_(memset)(&arch->vex_shadow2, 0, sizeof(VexGuestS390XState));
+ /* Mark all registers as undefined ... */
+ VG_(memset)(&arch->vex_shadow1, 0xFF, sizeof(VexGuestS390XState));
+ VG_(memset)(&arch->vex_shadow2, 0x00, sizeof(VexGuestS390XState));
+ /* ... except SP, FPC, and IA */
+ VG_(memset)((UChar *)&arch->vex_shadow1 + VG_O_STACK_PTR, 0x00, 8);
+ VG_(memset)((UChar *)&arch->vex_shadow1 + VG_O_FPC_REG, 0x00, 4);
+ VG_(memset)((UChar *)&arch->vex_shadow1 + VG_O_INSTR_PTR, 0x00, 8);
/* Put essential stuff into the new state. */
arch->vex.guest_SP = iifii.initial_client_SP;
arch->vex.guest_IA = iifii.initial_client_IP;
+ /* See sys_execve in <linux>/arch/s390/kernel/process.c */
+ arch->vex.guest_fpc = 0;
+ /* Tell the tool about the registers we just wrote */
+ VG_TRACK(post_reg_write, Vg_CoreStartup, /*tid*/1, VG_O_STACK_PTR, 8);
+ VG_TRACK(post_reg_write, Vg_CoreStartup, /*tid*/1, VG_O_FPC_REG, 4);
+ VG_TRACK(post_reg_write, Vg_CoreStartup, /*tid*/1, VG_O_INSTR_PTR, 8);
+ return;
+
# else
# error Unknown platform
# endif
Modified: trunk/coregrind/pub_core_machine.h
===================================================================
--- trunk/coregrind/pub_core_machine.h 2012-02-26 17:01:22 UTC (rev 12403)
+++ trunk/coregrind/pub_core_machine.h 2012-02-26 17:51:28 UTC (rev 12404)
@@ -103,6 +103,7 @@
# define VG_INSTR_PTR guest_IA
# define VG_STACK_PTR guest_SP
# define VG_FRAME_PTR guest_FP
+# define VG_FPC_REG guest_fpc
#else
# error Unknown arch
#endif
@@ -111,6 +112,7 @@
// Offsets for the Vex state
#define VG_O_STACK_PTR (offsetof(VexGuestArchState, VG_STACK_PTR))
#define VG_O_INSTR_PTR (offsetof(VexGuestArchState, VG_INSTR_PTR))
+#define VG_O_FPC_REG (offsetof(VexGuestArchState, VG_FPC_REG))
//-------------------------------------------------------------
|
|
From: Bart V. A. <bva...@ac...> - 2012-02-26 17:54:26
|
On Sun, Feb 26, 2012 at 5:00 PM, <sv...@va...> wrote: > @@ -352,7 +370,7 @@ > HChar* curr; > HChar* next; > Int ALIGN; > - ALIGN = sizeof(void*)-1; > + ALIGN = ((Int) ((UChar *)&s.x - (UChar *)&s)) - 1; > nbytes = (nbytes + ALIGN) & ~ALIGN; > curr = private_LibVEX_alloc_curr; > next = curr + nbytes; > Maybe it's a good idea to introduce a VEX_OFFSETOF() macro in order to improve readability of the above statement ? An additional benefit is that doing so would allow to remove the stack variable "s" again - at least if a name would be assigned to the structure definition. Bart. |
|
From: Philippe W. <phi...@sk...> - 2012-02-26 17:34:41
|
On Thu, 2012-02-23 at 10:24 +0100, Julian Seward wrote: > > If the below is ok, I will prepare 3 (cleaned up) patches: > > 1. a patch with the change below > > 2. the patch to have the inner ignoring the vgpreload > > of the outer (conditionalised on ENABLE_INNER) > > 3. an helgrind annotation patch (conditionalised on ENABLE_INNER) > > Ok for 2 and 3, but please please add the description from your > previous email as a big comment in 2, else nobody will understand > the rationale. > > For 1 we maybe should clean up the unwinders so that they are > allowed to travel inside the segment found by VG_(am_find_nsegment) > and nowhere else. This would maybe clean up some ad hoc checks. > Problem is VG_(am_find_nsegment) is expensive and Helgrind > can ask for an unwind very very often (100K+ times/sec) so I > would like to see if there is a way we can cache its results > on a per thread basis, somehow (since they will change only rarely). Attached in https://bugs.kde.org/show_bug.cgi?id=294812 a new version of the patch solving the unwinder problem by using register/deregister client requests in the inner. (tested an outer on an inner on x86/amd64/ppc64). Philippe |
|
From: <sv...@va...> - 2012-02-26 17:05:55
|
Author: florian Date: 2012-02-26 17:01:22 +0000 (Sun, 26 Feb 2012) New Revision: 12403 Log: Announce. Modified: trunk/NEWS Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2012-02-24 11:25:58 UTC (rev 12402) +++ trunk/NEWS 2012-02-26 17:01:22 UTC (rev 12403) @@ -54,6 +54,7 @@ 281482 valgrind's memcheck incorrect byte allocation count in realloc() for silly argument 282230 group allocator for small fixed size, use it for MC_Chunk/SEc vbit 283413 Fix wrong sanity check +283671 Robustize alignment computation in LibVEX_Alloc 286270 vgpreload is not friendly to 64->32 bit execs, gives ld.so warnings 286374 Running cachegrind with --branch-sim=yes on 64-bit PowerPC program fails 287260 Incorrect conditional jump or move depends on uninitialised value(s) |
|
From: <sv...@va...> - 2012-02-26 17:04:36
|
Author: florian
Date: 2012-02-26 17:00:03 +0000 (Sun, 26 Feb 2012)
New Revision: 2263
Log:
Do not assume that a pointer is the worst-aligned data type.
Fixes #283671
Modified:
trunk/pub/libvex.h
Modified: trunk/pub/libvex.h
===================================================================
--- trunk/pub/libvex.h 2012-02-24 12:16:11 UTC (rev 2262)
+++ trunk/pub/libvex.h 2012-02-26 17:00:03 UTC (rev 2263)
@@ -345,6 +345,24 @@
static inline void* LibVEX_Alloc ( Int nbytes )
{
+ struct {
+ char c;
+ union {
+ char c;
+ short s;
+ int i;
+ long l;
+ long long ll;
+ float f;
+ double d;
+ /* long double is currently not used and would increase alignment
+ unnecessarily. */
+ /* long double ld; */
+ void *pto;
+ void (*ptf)(void);
+ } x;
+ } s;
+
#if 0
/* Nasty debugging hack, do not use. */
return malloc(nbytes);
@@ -352,7 +370,7 @@
HChar* curr;
HChar* next;
Int ALIGN;
- ALIGN = sizeof(void*)-1;
+ ALIGN = ((Int) ((UChar *)&s.x - (UChar *)&s)) - 1;
nbytes = (nbytes + ALIGN) & ~ALIGN;
curr = private_LibVEX_alloc_curr;
next = curr + nbytes;
|