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
(32) |
2
(22) |
3
(47) |
4
(29) |
5
(18) |
6
(16) |
|
7
(21) |
8
(29) |
9
(23) |
10
(68) |
11
(20) |
12
(17) |
13
(17) |
|
14
(27) |
15
(26) |
16
(21) |
17
(13) |
18
(19) |
19
(29) |
20
(13) |
|
21
(9) |
22
(8) |
23
(29) |
24
(56) |
25
(21) |
26
(46) |
27
(33) |
|
28
(25) |
29
(41) |
30
(35) |
31
(28) |
|
|
|
|
From: Joseph M L. <val...@jo...> - 2005-08-16 22:14:26
|
Nicholas Nethercote wrote:
> On Sun, 24 Jul 2005, Joseph M Link wrote:
>
>> As I am sure you know, when using valgrind with inlined and -O2
>> optimized code, it becomes a little difficult to suppress based on
>> function name (as many calls are completely optimized away).
>
>
> Yes. We recommend compiling at lower levels of optimisation if possible
> for this reason.
>
>> For example, I would get reports such as:
>>
>> ==21368== at 0x1B90469A: operator new[](unsigned)
>> (vg_replace_malloc.c:138)
>> ==21368== by 0x806EE32: XmlNode::XmlNode(std::string const&,
>> std::string const&) (quick_allocator.hpp:97)
>>
>> The function I'd like to suppress is defined within
>> quick_allocator.hpp, but that call is inlined into every use of it.
>>
>> The attached patch adds support for suppression entries such as:
>>
>> {
>> allocator
>> Memcheck:Leak
>> fun:_Znaj
>> src:quick_allocator.hpp:97
>> }
>>
>> specifically, a 'src:' entry which can specify a source file with or
>> without a line number. This suppression would match both of the above
>> reports as long as debugging information is available in the
>> executable. If not, there is no detrimental effect, the suppression
>> just can't match.
>>
>> Any comments?
>
>
> This seems like not a bad idea. But why can't you suppress the above
> example? What does the output of --gen-suppressions=yes look like?
A function suppression can be created for the above example, but the
only function info that's available (the XmlNode constructor) is not the
function i want to suppress. It's the underlying allocator call that
has been optimized away that I want to suppress. In lieu of the
function call, I suppress at the particular line within the allocator
source code.
I should clarify that that XmlNode() constructor does *not* reside in
quick_allocator.hpp. I assume that the trace line is a mix of the last
function that actually has a frame and the real source line being executed.
Joe
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 20:59:29
|
On Sun, 24 Jul 2005, Joseph M Link wrote:
> As I am sure you know, when using valgrind with inlined and -O2 optimized
> code, it becomes a little difficult to suppress based on function name (as
> many calls are completely optimized away).
Yes. We recommend compiling at lower levels of optimisation if possible
for this reason.
> For example, I would get reports such as:
>
> ==21368== at 0x1B90469A: operator new[](unsigned)
> (vg_replace_malloc.c:138)
> ==21368== by 0x806EE32: XmlNode::XmlNode(std::string const&, std::string
> const&) (quick_allocator.hpp:97)
>
> The function I'd like to suppress is defined within quick_allocator.hpp, but
> that call is inlined into every use of it.
>
> The attached patch adds support for suppression entries such as:
>
> {
> allocator
> Memcheck:Leak
> fun:_Znaj
> src:quick_allocator.hpp:97
> }
>
> specifically, a 'src:' entry which can specify a source file with or without
> a line number. This suppression would match both of the above reports as
> long as debugging information is available in the executable. If not, there
> is no detrimental effect, the suppression just can't match.
>
> Any comments?
This seems like not a bad idea. But why can't you suppress the above
example? What does the output of --gen-suppressions=yes look like?
Nick
|
|
From: <sv...@va...> - 2005-08-16 10:21:52
|
Author: tom Date: 2005-08-16 11:21:46 +0100 (Tue, 16 Aug 2005) New Revision: 4436 Log: Update bug status documentation. Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 10:19:58 UTC (rev 4= 435) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 10:21:46 UTC (rev 4= 436) @@ -292,7 +292,7 @@ =20 I suppose it would be good to apply these. They seem low risk. =20 -FIXED-TRUNK: no +FIXED-TRUNK: 4429 FIXED-30BRANCH: no =20 ---------------------------------------------------------------- @@ -335,9 +335,7 @@ =20 ---------------------------------------------------------------- =20 -110685 Small test fixes +110875 Assertion when execve fails =20 -FIXED-TRUNK: 4429 +FIXED-TRUNK: 4435 FIXED-30BRANCH: TODO - - |
|
From: <sv...@va...> - 2005-08-16 10:20:09
|
Author: tom
Date: 2005-08-16 11:19:58 +0100 (Tue, 16 Aug 2005)
New Revision: 4435
Log:
Don't assert if execve fails. Fixes bug #110875.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2005-08-16 03:42:44 UTC (=
rev 4434)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2005-08-16 10:19:58 UTC (=
rev 4435)
@@ -2412,8 +2412,9 @@
=20
/* If we got here, then the execve failed. We've already made too
much of a mess of ourselves to continue, so we have to abort. */
+ vg_assert(FAILURE);
VG_(message)(Vg_UserMsg, "execve(%p(%s), %p, %p) failed, errno %d",
- ARG1, ARG1, ARG2, ARG3, -RES);
+ ARG1, ARG1, ARG2, ARG3, RES_unchecked);
VG_(message)(Vg_UserMsg, "EXEC FAILED: I can't recover from "
"execve() failing, so I'm dying.");
VG_(message)(Vg_UserMsg, "Add more stringent tests in PRE(sys_execve)=
, "
|
|
From: <sv...@va...> - 2005-08-16 03:42:46
|
Author: njn
Date: 2005-08-16 04:42:44 +0100 (Tue, 16 Aug 2005)
New Revision: 4434
Log:
minor fixes (probably not worth backporting)
Modified:
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/memcheck/docs/mc-manual.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/docs/mc-manual.xml 2005-08-16 03:34:56 UTC (rev 4433)
+++ trunk/memcheck/docs/mc-manual.xml 2005-08-16 03:42:44 UTC (rev 4434)
@@ -14,8 +14,8 @@
xreflabel=3D"Kinds of bugs that Memcheck can find">
<title>Kinds of bugs that Memcheck can find</title>
=20
-<para>Memcheck is Valgrind-1.0.X's checking mechanism bundled up
-into a tool. All reads and writes of memory are checked, and
+<para>Memcheck is Valgrind's heavyweight memory checking
+tool. All reads and writes of memory are checked, and
calls to malloc/new/free/delete are intercepted. As a result,
Memcheck can detect the following problems:</para>
=20
@@ -142,8 +142,7 @@
[default]</para>
<para><computeroutput>--workaround-gcc296-bugs=3Dyes</computeroutput=
></para>
<para>When enabled, assume that reads and writes some small
- distance below the stack pointer
- <computeroutput>%esp</computeroutput> are due to bugs in gcc
+ distance below the stack pointer are due to bugs in gcc
2.96, and does not report them. The "small distance" is 256
bytes by default. Note that gcc 2.96 is the default compiler
on some popular Linux distributions (RedHat 7.X, Mandrake)
@@ -234,10 +233,10 @@
=20
<para>In this example, Memcheck can't identify the address.
Actually the address is on the stack, but, for some reason, this
-is not a valid stack address -- it is below the stack pointer,
-<literal>%esp</literal>, and that isn't allowed. In this
+is not a valid stack address -- it is below the stack pointer
+and that isn't allowed. In this
particular case it's probably caused by gcc generating invalid
-code, a known bug in various flavours of gcc.</para>
+code, a known bug in various versions of gcc.</para>
=20
<para>Note that Memcheck only tells you that your program is
about to access memory at an illegal address. It can't stop the
@@ -853,7 +852,7 @@
<listitem>
<para>When the stack pointer register
(<literal>SP</literal>) moves up or down,
- <literal>A</literal> bits are set. The rule is that the area
+ A bits are set. The rule is that the area
from <literal>SP</literal> up to the base of the stack is
marked as accessible, and below <literal>SP</literal> is
inaccessible. (If that sounds illogical, bear in mind that
|
|
From: <sv...@va...> - 2005-08-16 03:34:58
|
Author: njn
Date: 2005-08-16 04:34:56 +0100 (Tue, 16 Aug 2005)
New Revision: 4433
Log:
wibbles
Modified:
trunk/massif/ms_main.c
trunk/memcheck/mac_malloc_wrappers.c
Modified: trunk/massif/ms_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/massif/ms_main.c 2005-08-16 03:29:50 UTC (rev 4432)
+++ trunk/massif/ms_main.c 2005-08-16 03:34:56 UTC (rev 4433)
@@ -782,7 +782,7 @@
=20
VGP_PUSHCC(VgpCliMalloc);
=20
- // First try and find the block.
+ // Remove the old block
hc =3D VG_(HT_remove)(malloc_list, (UWord)p_old);
if (hc =3D=3D NULL) {
VGP_POPCC(VgpCliMalloc);
Modified: trunk/memcheck/mac_malloc_wrappers.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mac_malloc_wrappers.c 2005-08-16 03:29:50 UTC (rev 443=
2)
+++ trunk/memcheck/mac_malloc_wrappers.c 2005-08-16 03:34:56 UTC (rev 443=
3)
@@ -297,7 +297,7 @@
if (mc =3D=3D NULL) {
MAC_(record_free_error) ( tid, p );
} else {
- /* check if its a matching free() / delete / delete [] */
+ /* check if it is a matching free() / delete / delete [] */
if (kind !=3D mc->allockind) {
MAC_(record_freemismatch_error) ( tid, p, mc );
}
|
|
From: <sv...@va...> - 2005-08-16 03:29:56
|
Author: njn
Date: 2005-08-16 04:29:50 +0100 (Tue, 16 Aug 2005)
New Revision: 4432
Log:
lots of little wibbles
Modified:
trunk/coregrind/m_oset.c
trunk/massif/ms_main.c
trunk/memcheck/mac_malloc_wrappers.c
Modified: trunk/coregrind/m_oset.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_oset.c 2005-08-16 03:28:47 UTC (rev 4431)
+++ trunk/coregrind/m_oset.c 2005-08-16 03:29:50 UTC (rev 4432)
@@ -724,4 +724,3 @@
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
-
Modified: trunk/massif/ms_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/massif/ms_main.c 2005-08-16 03:28:47 UTC (rev 4431)
+++ trunk/massif/ms_main.c 2005-08-16 03:29:50 UTC (rev 4432)
@@ -711,7 +711,7 @@
n_frees++;
=20
// Remove HP_Chunk from malloc_list
- hc =3D (HP_Chunk*)VG_(HT_remove)(malloc_list, (UWord)p);
+ hc =3D VG_(HT_remove)(malloc_list, (UWord)p);
if (NULL =3D=3D hc)
return; // must have been a bogus free()
tl_assert(n_heap_blocks > 0);
@@ -783,7 +783,7 @@
VGP_PUSHCC(VgpCliMalloc);
=20
// First try and find the block.
- hc =3D (HP_Chunk*)VG_(HT_remove)(malloc_list, (UWord)p_old);
+ hc =3D VG_(HT_remove)(malloc_list, (UWord)p_old);
if (hc =3D=3D NULL) {
VGP_POPCC(VgpCliMalloc);
return NULL; // must have been a bogus realloc()
Modified: trunk/memcheck/mac_malloc_wrappers.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mac_malloc_wrappers.c 2005-08-16 03:28:47 UTC (rev 443=
1)
+++ trunk/memcheck/mac_malloc_wrappers.c 2005-08-16 03:29:50 UTC (rev 443=
2)
@@ -67,12 +67,10 @@
/*--- Tracking malloc'd and free'd blocks ---*/
/*------------------------------------------------------------*/
=20
-/* Record malloc'd blocks. Nb: Addrcheck and Memcheck construct this
- separately in their respective initialisation functions. */
+/* Record malloc'd blocks. */
VgHashTable MAC_(malloc_list) =3D NULL;
=20
-/* Memory pools. Nb: Addrcheck and Memcheck construct this separately
- in their respective initialisation functions. */
+/* Memory pools. */
VgHashTable MAC_(mempool_list) =3D NULL;
=20
/* Records blocks after freeing. */
@@ -84,8 +82,6 @@
some of the oldest blocks in the queue at the same time. */
static void add_to_freed_queue ( MAC_Chunk* mc )
{
- MAC_Chunk* mc1;
-
/* Put it at the end of the freed list */
if (freed_list_end =3D=3D NULL) {
tl_assert(freed_list_start =3D=3D NULL);
@@ -103,6 +99,8 @@
volume below vg_clo_freelist_vol. */
=20
while (freed_list_volume > MAC_(clo_freelist_vol)) {
+ MAC_Chunk* mc1;
+
tl_assert(freed_list_start !=3D NULL);
tl_assert(freed_list_end !=3D NULL);
=20
@@ -140,11 +138,10 @@
mc->allockind =3D kind;
mc->where =3D VG_(record_ExeContext)(tid);
=20
- /* Paranoia ... ensure this area is off-limits to the client, so
+ /* Paranoia ... ensure the MAC_Chunk is off-limits to the client, so
the mc->data field isn't visible to the leak checker. If memory
- management is working correctly, anything pointer returned by
- VG_(malloc) should be noaccess as far as the client is
- concerned. */
+ management is working correctly, any pointer returned by VG_(mallo=
c)
+ should be noaccess as far as the client is concerned. */
if (!MAC_(check_noaccess)( (Addr)mc, sizeof(MAC_Chunk), NULL )) {
VG_(tool_panic)("create_MAC_Chunk: shadow area is accessible");
}=20
@@ -296,20 +293,17 @@
=20
cmalloc_n_frees++;
=20
- mc =3D (MAC_Chunk*)VG_(HT_remove) ( MAC_(malloc_list), (UWord)p );
+ mc =3D VG_(HT_remove) ( MAC_(malloc_list), (UWord)p );
if (mc =3D=3D NULL) {
MAC_(record_free_error) ( tid, p );
- VGP_POPCC(VgpCliMalloc);
- return;
+ } else {
+ /* check if its a matching free() / delete / delete [] */
+ if (kind !=3D mc->allockind) {
+ MAC_(record_freemismatch_error) ( tid, p, mc );
+ }
+ die_and_free_mem ( tid, mc, rzB );
}
=20
- /* check if its a matching free() / delete / delete [] */
- if (kind !=3D mc->allockind) {
- MAC_(record_freemismatch_error) ( tid, p, mc );
- }
-
- die_and_free_mem ( tid, mc, rzB );
-
VGP_POPCC(VgpCliMalloc);
}
=20
@@ -347,10 +341,10 @@
return NULL;
=20
/* Remove the old block */
- mc =3D (MAC_Chunk*)VG_(HT_remove) ( MAC_(malloc_list), (UWord)p_old )=
;
+ mc =3D VG_(HT_remove) ( MAC_(malloc_list), (UWord)p_old );
if (mc =3D=3D NULL) {
MAC_(record_free_error) ( tid, (Addr)p_old );
- /* Perhaps we should return to the program regardless. */
+ /* We return to the program regardless. */
VGP_POPCC(VgpCliMalloc);
return NULL;
}
@@ -416,14 +410,12 @@
=20
void MAC_(create_mempool)(Addr pool, UInt rzB, Bool is_zeroed)
{
- MAC_Mempool* mp;
+ MAC_Mempool* mp =3D VG_(malloc)(sizeof(MAC_Mempool));
+ mp->pool =3D pool;
+ mp->rzB =3D rzB;
+ mp->is_zeroed =3D is_zeroed;
+ mp->chunks =3D VG_(HT_construct)( 3001 ); // prime, not so big
=20
- mp =3D VG_(malloc)(sizeof(MAC_Mempool));
- mp->pool =3D pool;
- mp->rzB =3D rzB;
- mp->is_zeroed =3D is_zeroed;
- mp->chunks =3D VG_(HT_construct)( 3001 ); // prime, not so big
-
/* Paranoia ... ensure this area is off-limits to the client, so
the mp->data field isn't visible to the leak checker. If memory
management is working correctly, anything pointer returned by
@@ -434,7 +426,6 @@
}=20
=20
VG_(HT_add_node)( MAC_(mempool_list), mp );
- =20
}
=20
void MAC_(destroy_mempool)(Addr pool)
@@ -467,17 +458,14 @@
=20
void MAC_(mempool_alloc)(ThreadId tid, Addr pool, Addr addr, SizeT size)
{
- MAC_Mempool* mp;
+ MAC_Mempool* mp =3D VG_(HT_lookup) ( MAC_(mempool_list), (UWord)pool =
);
=20
- mp =3D VG_(HT_lookup) ( MAC_(mempool_list), (UWord)pool );
-
if (mp =3D=3D NULL) {
MAC_(record_illegal_mempool_error) ( tid, pool );
- return;
+ } else {
+ MAC_(new_block)(tid, addr, size, /*ignored*/0, mp->rzB, mp->is_zer=
oed,
+ MAC_AllocCustom, mp->chunks);
}
-
- MAC_(new_block)(tid, addr, size, /*ignored*/0, mp->rzB, mp->is_zeroed=
,
- MAC_AllocCustom, mp->chunks);
}
=20
void MAC_(mempool_free)(Addr pool, Addr addr)
@@ -492,7 +480,7 @@
return;
}
=20
- mc =3D (MAC_Chunk*)VG_(HT_remove)(mp->chunks, (UWord)addr);
+ mc =3D VG_(HT_remove)(mp->chunks, (UWord)addr);
if (mc =3D=3D NULL) {
MAC_(record_free_error)(tid, (Addr)addr);
return;
|
|
From: <sv...@va...> - 2005-08-16 03:28:56
|
Author: njn
Date: 2005-08-16 04:28:47 +0100 (Tue, 16 Aug 2005)
New Revision: 4431
Log:
Make the nightly script say early on if the results have changed in
the last 24 hours. This saves you from having to scroll down to
determine this when the number of failures is large (eg on PPC).
Modified:
trunk/nightly/bin/nightly
Modified: trunk/nightly/bin/nightly
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/nightly/bin/nightly 2005-08-16 02:31:08 UTC (rev 4430)
+++ trunk/nightly/bin/nightly 2005-08-16 03:28:47 UTC (rev 4431)
@@ -124,13 +124,20 @@
echo "Nightly build on" $ABT_MACHINE "(" $ABT_DETAILS ")" \
"started at" $ABT_START >> final
=20
+# If the results differ from 24 hours ago, print extra stuff.
+diff -C1 old.short new.short > diff.short
+changed=3D$?
+
+if [ $changed !=3D 0 ] ; then
+ echo "Results differ from 24 hours ago" >> final
+else
+ echo "Results unchanged from 24 hours ago" >> final
+fi
+
# Always show the current results.
cat new.short >> final
=20
-# If the results differ from 24 hours ago, print extra stuff.
-diff -C1 old.short new.short > diff.short
-
-if [ $? !=3D 0 ] ; then
+if [ $changed !=3D 0 ] ; then
echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D" >> final
echo "=3D=3D Results from 24 hours ago =3D=3D" >> f=
inal
echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D" >> final
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 02:48:09
|
On Sat, 13 Aug 2005, Dirk Mueller wrote:
> any idea how to suppress this:
>
> ==7046== Conditional jump or move depends on uninitialised value(s)
> ==7046== at 0x1B8F5569: index (in /lib/ld-2.3.5.so)
> ==7046== by 0x52BFD9EA: ???
> ==7046== by 0x1B8EAD0E: _dl_map_object (in /lib/ld-2.3.5.so)
> ...
>
> --gen-suppression=yes prints this:
>
> {
> <insert a suppression name here>
> Memcheck:Cond
> fun:index
> ???:??? # unknown, suppression will not work, sorry
> fun:_dl_map_object
> ...
> }
Try the attached (untested) patch, which will generate "obj:*" for that
line rather than "???:???". It should now match the "???". Let me know
if it works and I'll commit it.
N |
|
From: Tom H. <to...@co...> - 2005-08-16 02:41:49
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-08-16 03:30:03 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 183 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <sv...@va...> - 2005-08-16 02:31:12
|
Author: njn Date: 2005-08-16 03:31:08 +0100 (Tue, 16 Aug 2005) New Revision: 4430 Log: update Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 02:30:24 UTC (rev 4= 429) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 02:31:08 UTC (rev 4= 430) @@ -333,3 +333,11 @@ FIXED-TRUNK: 4427 FIXED-30BRANCH: TODO =20 +---------------------------------------------------------------- + +110685 Small test fixes + +FIXED-TRUNK: 4429 +FIXED-30BRANCH: TODO + + |
|
From: <sv...@va...> - 2005-08-16 02:30:30
|
Author: njn
Date: 2005-08-16 03:30:24 +0100 (Tue, 16 Aug 2005)
New Revision: 4429
Log:
Fixes for #110657, based on Jakub Jelinek's patch:
- filter out L3 warning messages so they don't break Cachegrind's regtest=
s
- handle lack of mq support gracefully in mq.c
Modified:
trunk/cachegrind/cg-x86.c
trunk/cachegrind/tests/filter_stderr
trunk/none/tests/mq.c
Modified: trunk/cachegrind/cg-x86.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/cg-x86.c 2005-08-16 02:21:13 UTC (rev 4428)
+++ trunk/cachegrind/cg-x86.c 2005-08-16 02:30:24 UTC (rev 4429)
@@ -108,8 +108,7 @@
VG_(tool_panic)("IA-64 cache detected?!");
=20
case 0x22: case 0x23: case 0x25: case 0x29:=20
- VG_(message)(Vg_DebugMsg,=20
- "warning: L3 cache detected but ignored\n");
+ VG_(message)(Vg_DebugMsg, "warning: L3 cache detected but igno=
red");
break;
=20
/* These are sectored, whatever that means */
Modified: trunk/cachegrind/tests/filter_stderr
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/tests/filter_stderr 2005-08-16 02:21:13 UTC (rev 442=
8)
+++ trunk/cachegrind/tests/filter_stderr 2005-08-16 02:30:24 UTC (rev 442=
9)
@@ -13,7 +13,7 @@
# Remove numbers from I1/D1/L2/L2i/L2d "misses:" and "miss rates:" lines
sed "s/\(\(I1\|D1\|L2\|L2i\|L2d\) *\(misses\|miss rate\):\)[ 0-9,()+rdw%=
\.]*$/\1/" |
=20
-# Remove warnings lines for P4s:
+# Remove CPUID warnings lines for P4s and other machines
sed "/warning: Pentium with 12 K micro-op instruction trace cache/d" |
-sed "/Simulating a 16 KB cache with 32 B lines/d"
-
+sed "/Simulating a 16 KB cache with 32 B lines/d" |
+sed "/warning: L3 cache detected but ignored/d"
Modified: trunk/none/tests/mq.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/mq.c 2005-08-16 02:21:13 UTC (rev 4428)
+++ trunk/none/tests/mq.c 2005-08-16 02:30:24 UTC (rev 4429)
@@ -24,6 +24,8 @@
=20
if ((mqdw =3D mq_open("/valgrind-mqueue", O_CREAT|O_EXCL|O_WRONLY, 060=
0, &mqa)) < 0)
{
+ if (errno =3D=3D ENOSYS)
+ exit(0);
perror("mq_open");
exit(1);
}
|
|
From: Tom H. <th...@cy...> - 2005-08-16 02:27:22
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-08-16 03:15:03 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 182 tests, 15 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/cmpxchg8b (stdout) none/tests/x86/cmpxchg8b (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-16 02:24:05
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-08-16 03:10:07 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 182 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <sv...@va...> - 2005-08-16 02:21:16
|
Author: njn Date: 2005-08-16 03:21:13 +0100 (Tue, 16 Aug 2005) New Revision: 4428 Log: update Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 02:20:17 UTC (rev 4= 427) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 02:21:13 UTC (rev 4= 428) @@ -326,3 +326,10 @@ FIXED-TRUNK: TODO FIXED-30BRANCH: TODO =20 +---------------------------------------------------------------- + +Description of leak errors in manual. + +FIXED-TRUNK: 4427 +FIXED-30BRANCH: TODO + |
|
From: <sv...@va...> - 2005-08-16 02:20:20
|
Author: njn Date: 2005-08-16 03:20:17 +0100 (Tue, 16 Aug 2005) New Revision: 4427 Log: How do you like this: there was no proper description in the manual=20 of leak error messages, nor any examples. So I added one, and moved what info there was about leaks out of its separate section, and into the section describing all the kinds of error message. BACKPORT TO 3_0_X Modified: trunk/memcheck/docs/mc-manual.xml Modified: trunk/memcheck/docs/mc-manual.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/memcheck/docs/mc-manual.xml 2005-08-16 01:41:43 UTC (rev 4426) +++ trunk/memcheck/docs/mc-manual.xml 2005-08-16 02:20:17 UTC (rev 4427) @@ -506,6 +506,85 @@ </sect2> =20 =20 +<sect2 id=3D"mc-manual.leaks" xreflabel=3D"Memory leak detection"> +<title>Memory leak detection</title> + +<para>Memcheck keeps track of all memory blocks issued in +response to calls to malloc/calloc/realloc/new. So when the +program exits, it knows which blocks have not been freed. +</para> + +<para>If <computeroutput>--leak-check</computeroutput> is set +appropriately, for each remaining block, Memcheck scans the entire +address space of the process, looking for pointers to the block. +Each block fits into one of the three following categories.</para> + +<itemizedlist> + + <listitem> + <para>Still reachable: A pointer to the start + of the block is found. This usually indicates programming + sloppiness; since the block is still pointed at, the + programmer could, at least in principle, free'd it before + program exit. Because these are very common and arguably + not a problem, Memcheck won't report such blocks unless + <computeroutput>--show-reachable=3Dyes</computeroutput> is + specified.</para> + </listitem> + + <listitem> + <para>Possibly lost, or "dubious": A pointer to the + interior of the block is found. The pointer might originally + have pointed to the start and have been moved along, or it + might be entirely unrelated. Memcheck deems such a block as + "dubious", because it's unclear whether or not a pointer to it + still exists.</para> + </listitem> + + <listitem> + <para>Definitely lost, or "leaked": The worst + outcome is that no pointer to the block can be found. The + block is classified as "leaked", because the programmer could + not possibly have freed it at program exit, since no pointer + to it exists. This is likely a symptom of having lost the + pointer at some earlier point in the program.</para> + </listitem> + +</itemizedlist> + +<para>For each block mentioned, Memcheck will also tell you where +the block was allocated. It cannot tell you how or why the +pointer to a leaked block has been lost; you have to work that +out for yourself. In general, you should attempt to ensure your +programs do not have any leaked or dubious blocks at exit.</para> + +<para>For example:</para> +<programlisting><![CDATA[ +8 bytes in 1 blocks are definitely lost in loss record 1 of 14 + at 0x........: malloc (vg_replace_malloc.c:...) + by 0x........: mk (leak-tree.c:11) + by 0x........: main (leak-tree.c:39) + +88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss= record 13 of 14 + at 0x........: malloc (vg_replace_malloc.c:...) + by 0x........: mk (leak-tree.c:11) + by 0x........: main (leak-tree.c:25) +]]></programlisting> + +<para>The first message describes a simple case of a single 8 byte +block that has been definitely lost. The second case +mentions both "direct" and "indirect" leaks. The distinction is +that a direct leak is a block which has no pointers to it. An +indirect leak is a block which is only pointed to by other leaked +blocks. Both kinds of leak are bad.</para> + +<para>The precise area of memory in which Memcheck searches for +pointers is: all naturally-aligned 4-byte words for which all A +bits indicate addressibility and all V bits indicated that the +stored value is actually valid.</para> + +</sect2> + </sect1> =20 =20 @@ -931,63 +1010,6 @@ =20 =20 =20 -<sect1 id=3D"mc-manual.leaks" xreflabel=3D"Memory leak detection"> -<title>Memory leak detection</title> - -<para>Memcheck keeps track of all memory blocks issued in -response to calls to malloc/calloc/realloc/new. So when the -program exits, it knows which blocks are still outstanding -- -have not been returned, in other words. Ideally, you want your -program to have no blocks still in use at exit. But many -programs do.</para> - -<para>For each such block, Memcheck scans the entire address -space of the process, looking for pointers to the block. One of -three situations may result:</para> - -<itemizedlist> - - <listitem> - <para>A pointer to the start of the block is found. This - usually indicates programming sloppiness; since the block is - still pointed at, the programmer could, at least in - principle, free'd it before program exit.</para> - </listitem> - - <listitem> - <para>A pointer to the interior of the block is found. The - pointer might originally have pointed to the start and have - been moved along, or it might be entirely unrelated. - Memcheck deems such a block as "dubious", that is, possibly - leaked, because it's unclear whether or not a pointer to it - still exists.</para> - </listitem> - - <listitem> - <para>The worst outcome is that no pointer to the block can - be found. The block is classified as "leaked", because the - programmer could not possibly have free'd it at program exit, - since no pointer to it exists. This might be a symptom of - having lost the pointer at some earlier point in the - program.</para> - </listitem> - -</itemizedlist> - -<para>Memcheck reports summaries about leaked and dubious blocks. -For each such block, it will also tell you where the block was -allocated. This should help you figure out why the pointer to it -has been lost. In general, you should attempt to ensure your -programs do not have any leaked or dubious blocks at exit.</para> - -<para>The precise area of memory in which Memcheck searches for -pointers is: all naturally-aligned 4-byte words for which all A -bits indicate addressibility and all V bits indicated that the -stored value is actually valid.</para> - -</sect1> - - <sect1 id=3D"mc-manual.clientreqs" xreflabel=3D"Client requests"> <title>Client Requests</title> =20 |
|
From: Tom H. <th...@cy...> - 2005-08-16 02:20:06
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-08-16 03:10:07 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 160 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-16 02:16:36
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-08-16 03:05:11 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 160 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 159 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 16 03:11:49 2005 --- new.short Tue Aug 16 03:16:27 2005 *************** *** 8,10 **** ! == 159 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 160 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: Tom H. <th...@cy...> - 2005-08-16 02:12:23
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-08-16 03:00:04 BST Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 160 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 159 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 16 03:05:09 2005 --- new.short Tue Aug 16 03:12:11 2005 *************** *** 8,10 **** ! == 159 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 160 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: <sv...@va...> - 2005-08-16 01:41:47
|
Author: njn Date: 2005-08-16 02:41:43 +0100 (Tue, 16 Aug 2005) New Revision: 4426 Log: update Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 01:39:34 UTC (rev 4= 425) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-08-16 01:41:43 UTC (rev 4= 426) @@ -84,7 +84,13 @@ FIXED-TRUNK: yes (1319/4334) FIXED-30BRANCH: yes (1326, and 4334 was copied across as part of 4364) =20 +---------------------------------------------------------------- =20 +Give more info about seginfo dropping. + +FIXED-TRUNK: yes (4425) +FIXED-30BRANCH: no + ------------------------------------------------------------------------ --- Bugs reported after 3.0.0 shipped --- ------------------------------------------------------------------------ |
|
From: <sv...@va...> - 2005-08-16 01:39:41
|
Author: njn Date: 2005-08-16 02:39:34 +0100 (Tue, 16 Aug 2005) New Revision: 4425 Log: Give more info about seginfo dropping. Modified: trunk/coregrind/m_signals.c Modified: trunk/coregrind/m_signals.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/coregrind/m_signals.c 2005-08-15 13:29:43 UTC (rev 4424) +++ trunk/coregrind/m_signals.c 2005-08-16 01:39:34 UTC (rev 4425) @@ -1831,6 +1831,16 @@ sigNo, signame(sigNo)); VG_(message)(Vg_UserMsg, " This may be because one of your programs h= as consumed your"); VG_(message)(Vg_UserMsg, " ration of siginfo structures."); + VG_(printf)( +" For more information, see:\n" +" http://kerneltrap.org/mailarchive/1/message/25599/thread\n" +" Basically, some program on your system is building up a large queue o= f\n" +" pending signals, and this causes the siginfo data for other signals t= o\n" +" be dropped because it's exceeding a system limit. However, Valgrind\= n" +" absolutely needs siginfo for SIGSEGV. A workaround is to track down = the\n" +" offending program and avoid running it while using Valgrind, but ther= e\n" +" is no easy way to do this. Apparently the problem was fixed in kerne= l\n" +" 2.6.12.\n"); =20 /* It's a fatal signal, so we force the default handler. */ VG_(set_default_handler)(sigNo); |