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
(11) |
2
(26) |
3
(15) |
4
(4) |
|
5
(2) |
6
(7) |
7
(6) |
8
(22) |
9
(15) |
10
(13) |
11
(8) |
|
12
(6) |
13
(4) |
14
(9) |
15
(5) |
16
(2) |
17
(7) |
18
(7) |
|
19
(8) |
20
(14) |
21
(7) |
22
(21) |
23
(12) |
24
(12) |
25
(6) |
|
26
(6) |
27
(12) |
28
(17) |
29
(8) |
30
(8) |
|
|
|
From: Bart V. A. <bva...@ac...> - 2010-09-07 16:48:41
|
On Tue, Sep 7, 2010 at 1:10 PM, Christian Borntraeger <bor...@de...> wrote: > > Am 07.09.2010 13:04, schrieb Bart Van Assche: > > The above commit indeed removes r11304. Revision 11304 was committed > > too early - it was committed while I was searching for the cause of an > > assertion failure triggered by a signal handler that was invoked on an > > alternate stack. > > > > None of the callers of the modified function should invoke it with len == 0. > > > Look at coregrind/m_main.c:2188 > > VG_TRACK( die_mem_stack, > seg->start, > the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB > - seg->start ); > > If the environment happens to be the right size, > (the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB) might be exactly > on a page start and therefore identical to seg-start. This would > result in len=0, no? > > (coincidentally seen here on my system). Thanks for the feedback. Does r11342 (or later) work on your system without triggering an assertion failure ? Bart. |
|
From: <sv...@va...> - 2010-09-07 16:33:02
|
Author: bart
Date: 2010-09-07 17:32:53 +0100 (Tue, 07 Sep 2010)
New Revision: 11342
Log:
Consistency improvement: made sure that VG_TRACK(die_mem_stack, address, len)
is not invoked with a zero third argument.
Modified:
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2010-09-07 16:31:24 UTC (rev 11341)
+++ trunk/coregrind/m_main.c 2010-09-07 16:32:53 UTC (rev 11342)
@@ -2165,7 +2165,9 @@
VG_(deleteXA)( addr2dihandle );
/* Also do the initial stack permissions. */
- { NSegment const* seg
+ {
+ SSizeT inaccessible_len;
+ NSegment const* seg
= VG_(am_find_nsegment)( the_iifii.initial_client_SP );
vg_assert(seg);
vg_assert(seg->kind == SkAnonC);
@@ -2181,12 +2183,13 @@
is required (VG_STACK_REDZONE_SZB). setup_client_stack()
will have allocated an extra page if a red zone is required,
to be on the safe side. */
- vg_assert(the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB
- >= seg->start);
- VG_TRACK( die_mem_stack,
- seg->start,
- the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB
- - seg->start );
+ inaccessible_len = the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB
+ - seg->start;
+ vg_assert(inaccessible_len >= 0);
+ if (inaccessible_len > 0)
+ VG_TRACK( die_mem_stack,
+ seg->start,
+ inaccessible_len );
VG_(debugLog)(2, "main", "mark stack inaccessible %010lx-%010lx\n",
seg->start,
the_iifii.initial_client_SP-1 - VG_STACK_REDZONE_SZB);
|
|
From: <sv...@va...> - 2010-09-07 16:31:33
|
Author: bart Date: 2010-09-07 17:31:24 +0100 (Tue, 07 Sep 2010) New Revision: 11341 Log: Updated Subversion ignore list. Modified: trunk/memcheck/tests/ppc32/ trunk/memcheck/tests/ppc64/ Property changes on: trunk/memcheck/tests/ppc32 ___________________________________________________________________ Name: svn:ignore + .deps Makefile Makefile.in Property changes on: trunk/memcheck/tests/ppc64 ___________________________________________________________________ Name: svn:ignore + .deps Makefile Makefile.in |
|
From: Christian B. <bor...@de...> - 2010-09-07 11:10:56
|
Am 07.09.2010 13:04, schrieb Bart Van Assche:
> The above commit indeed removes r11304. Revision 11304 was committed
> too early - it was committed while I was searching for the cause of an
> assertion failure triggered by a signal handler that was invoked on an
> alternate stack.
>
> None of the callers of the modified function should invoke it with len == 0.
Look at coregrind/m_main.c:2188
VG_TRACK( die_mem_stack,
seg->start,
the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB
- seg->start );
If the environment happens to be the right size,
(the_iifii.initial_client_SP - VG_STACK_REDZONE_SZB) might be exactly
on a page start and therefore identical to seg-start. This would
result in len=0, no?
(coincidentially seen here on my system).
|
|
From: Bart V. A. <bva...@ac...> - 2010-09-07 11:04:23
|
On Tue, Sep 7, 2010 at 12:59 PM, Christian Borntraeger
<bor...@de...> wrote:
> Am 02.09.2010 16:50, schrieb sv...@va...:
>> Author: bart
>> Date: 2010-09-02 15:50:41 +0100 (Thu, 02 Sep 2010)
>> New Revision: 11329
>>
>> Log:
>> Made sure that DRD processes client programs that use SA_ONSTACK
>> correctly (e.g. Wine).
>>
>>
>> Modified:
>> trunk/drd/drd_main.c
>>
>>
>> Modified: trunk/drd/drd_main.c
>> ===================================================================
>> --- trunk/drd/drd_main.c 2010-09-02 14:44:17 UTC (rev 11328)
>> +++ trunk/drd/drd_main.c 2010-09-02 14:50:41 UTC (rev 11329)
>> @@ -326,9 +326,6 @@
>> {
>> const Addr a2 = a1 + len;
>>
>> - if (len == 0)
>> - return;
>> -
>> tl_assert(a1 < a2);
>>
>> if (UNLIKELY(DRD_(any_address_is_traced)()))
>
> Bart,
>
> this basically removes r11304. Was this an oversight?
> len=0 can really happen in real code,e.g. on startup
> if the stack pointer is exactly on a page boundary
> and valgrind_main does initial stack permissions.
> (client_SP == seg->start)
The above commit indeed removes r11304. Revision 11304 was committed
too early - it was committed while I was searching for the cause of an
assertion failure triggered by a signal handler that was invoked on an
alternate stack.
None of the callers of the modified function should invoke it with len == 0.
Bart.
|
|
From: Christian B. <bor...@de...> - 2010-09-07 10:59:41
|
Am 02.09.2010 16:50, schrieb sv...@va...:
> Author: bart
> Date: 2010-09-02 15:50:41 +0100 (Thu, 02 Sep 2010)
> New Revision: 11329
>
> Log:
> Made sure that DRD processes client programs that use SA_ONSTACK
> correctly (e.g. Wine).
>
>
> Modified:
> trunk/drd/drd_main.c
>
>
> Modified: trunk/drd/drd_main.c
> ===================================================================
> --- trunk/drd/drd_main.c 2010-09-02 14:44:17 UTC (rev 11328)
> +++ trunk/drd/drd_main.c 2010-09-02 14:50:41 UTC (rev 11329)
> @@ -326,9 +326,6 @@
> {
> const Addr a2 = a1 + len;
>
> - if (len == 0)
> - return;
> -
> tl_assert(a1 < a2);
>
> if (UNLIKELY(DRD_(any_address_is_traced)()))
Bart,
this basically removes r11304. Was this an oversight?
len=0 can really happen in real code,e.g. on startup
if the stack pointer is exactly on a page boundary
and valgrind_main does initial stack permissions.
(client_SP == seg->start)
Please consider readding this check
Christian
|