You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
(3) |
3
(14) |
4
(33) |
5
(1) |
6
(11) |
7
(4) |
8
(3) |
|
9
|
10
(13) |
11
(23) |
12
(4) |
13
(4) |
14
(7) |
15
(1) |
|
16
|
17
(29) |
18
(24) |
19
(5) |
20
(8) |
21
(8) |
22
(3) |
|
23
|
24
(1) |
25
(9) |
26
(4) |
27
(8) |
28
(7) |
29
(5) |
|
30
(6) |
31
(3) |
|
|
|
|
|
|
From: Brian C. <cr...@fi...> - 2005-10-17 21:13:57
|
The bytes are not _only_ uninitalized, however, they are also beyond the end of the allocated data.
(don't know if that makes a difference).
-- Brian
Yeshurun, Meir wrote:
> The purpose of this little program was to do exactly that. My question
> is why isn't the error suppressed by specifying --partial-loads-ok=yes.
>
> Meir
>
> -----Original Message-----
> From: Brian Crowder [mailto:cr...@fi...]
> Sent: Monday, October 17, 2005 11:03 PM
> To: Yeshurun, Meir
> Cc: Tom Hughes; val...@li...
> Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
> compared to purify
>
>
> "XXX" is uninitialized memory. Ints are assumed to be 4-byte:
>
> a = { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9', 0,
> XXX, XXX }
> ((int*)a + 9) = { ............................................RRR, RRR,
> RRR, RRR }
>
> the last two bytes being read in the int dereference are uninitialized
> memory.
>
>
> -- Brian
>
> Yeshurun, Meir wrote:
>
>>The following program generates an invalid read even when explicitly
>>specifying --partial-loads-ok=yes. Am I missing something here?
>>
>>#include <cstring>
>>#include <iostream>
>>
>>using namespace std;
>>
>>int main()
>>{
>> char *a = new char[11];
>> strcpy(a, "0123456789");
>> int b = *(int *)(a + 9);
>>}
>>
>>
>>Thanks,
>>
>>Meir
>>
>>-----Original Message-----
>>From: val...@li...
>>[mailto:val...@li...] On Behalf Of Tom
>>Hughes
>>Sent: Monday, October 17, 2005 9:07 PM
>>To: val...@li...
>>Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing
>
> terribly
>
>>compared to purify
>>
>>In message
>>
>
> <942...@ha...>
>
>> "Yeshurun, Meir" <mei...@in...> wrote:
>>
>>
>>
>>>There is one issue though: It looks like Valgrind reports partial
>>
>>loads
>>
>>
>>>as errors by default. I think this shouldn't be the default behavior.
>>
>>
>>Actually valgrind doesn't report any loads as errors - it only
>>reports an error when you use an undefined value in a way that
>>would effect the result of the program. In other words when a
>>conditional jump depends on it or you use it as a pointer and
>>read or write through that pointer.
>>
>>It tracks definedness at bit level, so a partial load will mark
>>some bits as defined and leaves others alone. If you then later
>>use one of the undefined bits it will complain.
>>
>>There are edge cases where it thinks a bit is used when it isn't
>>really but they are rare.
>>
>>I think you need to explain what you mean more fully.
>>
>>Tom
>>
>
>
>
>
|
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 21:06:33
|
The purpose of this little program was to do exactly that. My question
is why isn't the error suppressed by specifying =
--partial-loads-ok=3Dyes.
Meir
-----Original Message-----
From: Brian Crowder [mailto:cr...@fi...]=20
Sent: Monday, October 17, 2005 11:03 PM
To: Yeshurun, Meir
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
"XXX" is uninitialized memory. Ints are assumed to be 4-byte:
a =3D { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9', =
0,
XXX, XXX }
((int*)a + 9) =3D { ............................................RRR, =
RRR,
RRR, RRR }
the last two bytes being read in the int dereference are uninitialized
memory.
-- Brian
Yeshurun, Meir wrote:
> The following program generates an invalid read even when explicitly
> specifying --partial-loads-ok=3Dyes. Am I missing something here?
>=20
> #include <cstring>
> #include <iostream>
>=20
> using namespace std;
>=20
> int main()
> {
> char *a =3D new char[11];
> strcpy(a, "0123456789");
> int b =3D *(int *)(a + 9); =20
> }
>=20
>=20
> Thanks,
>=20
> Meir
>=20
> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...] On Behalf Of Tom
> Hughes
> Sent: Monday, October 17, 2005 9:07 PM
> To: val...@li...
> Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing
terribly
> compared to purify
>=20
> In message
>
<942...@ha...>
> "Yeshurun, Meir" <mei...@in...> wrote:
>=20
>=20
>>There is one issue though: It looks like Valgrind reports partial
>=20
> loads
>=20
>>as errors by default. I think this shouldn't be the default behavior.
>=20
>=20
> Actually valgrind doesn't report any loads as errors - it only
> reports an error when you use an undefined value in a way that
> would effect the result of the program. In other words when a
> conditional jump depends on it or you use it as a pointer and
> read or write through that pointer.
>=20
> It tracks definedness at bit level, so a partial load will mark
> some bits as defined and leaves others alone. If you then later
> use one of the undefined bits it will complain.
>=20
> There are edge cases where it thinks a bit is used when it isn't
> really but they are rare.
>=20
> I think you need to explain what you mean more fully.
>=20
> Tom
>=20
|
|
From: Brian C. <cr...@fi...> - 2005-10-17 21:03:36
|
"XXX" is uninitialized memory. Ints are assumed to be 4-byte:
a = { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9', 0, XXX, XXX }
((int*)a + 9) = { ............................................RRR, RRR, RRR, RRR }
the last two bytes being read in the int dereference are uninitialized memory.
-- Brian
Yeshurun, Meir wrote:
> The following program generates an invalid read even when explicitly
> specifying --partial-loads-ok=yes. Am I missing something here?
>
> #include <cstring>
> #include <iostream>
>
> using namespace std;
>
> int main()
> {
> char *a = new char[11];
> strcpy(a, "0123456789");
> int b = *(int *)(a + 9);
> }
>
>
> Thanks,
>
> Meir
>
> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...] On Behalf Of Tom
> Hughes
> Sent: Monday, October 17, 2005 9:07 PM
> To: val...@li...
> Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly
> compared to purify
>
> In message
> <942...@ha...>
> "Yeshurun, Meir" <mei...@in...> wrote:
>
>
>>There is one issue though: It looks like Valgrind reports partial
>
> loads
>
>>as errors by default. I think this shouldn't be the default behavior.
>
>
> Actually valgrind doesn't report any loads as errors - it only
> reports an error when you use an undefined value in a way that
> would effect the result of the program. In other words when a
> conditional jump depends on it or you use it as a pointer and
> read or write through that pointer.
>
> It tracks definedness at bit level, so a partial load will mark
> some bits as defined and leaves others alone. If you then later
> use one of the undefined bits it will complain.
>
> There are edge cases where it thinks a bit is used when it isn't
> really but they are rare.
>
> I think you need to explain what you mean more fully.
>
> Tom
>
|
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 20:56:06
|
The following program generates an invalid read even when explicitly
specifying --partial-loads-ok=3Dyes. Am I missing something here?
#include <cstring>
#include <iostream>
using namespace std;
int main()
{
char *a =3D new char[11];
strcpy(a, "0123456789");
int b =3D *(int *)(a + 9); =20
}
Thanks,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Monday, October 17, 2005 9:07 PM
To: val...@li...
Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
In message
<942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> There is one issue though: It looks like Valgrind reports partial
loads
> as errors by default. I think this shouldn't be the default behavior.
Actually valgrind doesn't report any loads as errors - it only
reports an error when you use an undefined value in a way that
would effect the result of the program. In other words when a
conditional jump depends on it or you use it as a pointer and
read or write through that pointer.
It tracks definedness at bit level, so a partial load will mark
some bits as defined and leaves others alone. If you then later
use one of the undefined bits it will complain.
There are edge cases where it thinks a bit is used when it isn't
really but they are rare.
I think you need to explain what you mean more fully.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: John R.
|
> char* buf = malloc(5); > buf[7] = 0; > Valgrind correctly reports the problems, although incorrectly says that > buf[7] is a write 2 bytes beyond the end of the memory when it's 3 bytes > beyond. Under the schema that is used by average programmers, Purify is correct that a write to buf[7] is 3 bytes beyond the end of the block that was allocated by malloc(5): "Address 0x80b4927 is 3 bytes past end of a malloc'd block at 0x80b4920 of 5 bytes." The schema is: number the bytes. The address of the last allocated byte is &buf[4], and &buf[7] - &buf[4] is 3. &buf[5] is "one byte beyond the end." However, under the schema that is used by the most experienced and skillful C programmers, Valgrind is correct that a write to buf[7] is 2 bytes beyond the end of the block. The schema is: number the [zero-width] boundaries between the bytes, and associate a byte with its lower-numbered boundary. The end of the block is the _boundary_ associated with buf[5], and &buf[7] - &buf[5] is 2. &buf[5] is "zero bytes beyond the end" because the boundary between the byte associated with offset +4 and the byte associated with offset +5 _is_ the [zero-width] end of the block. -- |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 20:28:15
|
Actually, according to the definition of that error, Valgrind should
report it here.
You can't expect a memory checker to find mathematical proofs that a
value computed from a set of values that include underfined ones is
deterministic. You can always find more and more complex examples of
this sort of thing.
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Scott
Long
Sent: Monday, October 17, 2005 9:43 PM
To: val...@li...
Subject: [Valgrind-users] Valgrind erroneously reports uninitialized bit
Valgrind 3.0.1 erroneously reports an error ("Conditional jump or move=20
depends on uninitialised value(s)") on the if-statements of both of the=20
following code snippets (compiled with GCC 3.2.3, no optimization):
int main()
{
int uninit;
int two =3D 2;
uninit *=3D two;
if(!(uninit & 1)) // there should be no error here
{
printf("Hello, world!\n");
}
return 0;
}
-----
int main()
{
int uninit;
uninit ^=3D uninit;
if(!(uninit & 1)) // there should be no error here
{
printf("Hello, world!\n");
}
return 0;
}
Scott
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 20:19:50
|
-----Original Message----- From: Yeshurun, Meir=20 Sent: Monday, October 17, 2005 10:19 PM To: 'Nick Lindridge' Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly compared to purify > I don't like to compare great free opensource efforts against highly > expensive commercial ones, That's not what makes the comparison "unfair". What does, is that with purify you can't just write purify a.out and have you program memory checked. It doesn't run directly on your executable like Valgrind. Regards, Meir |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 20:09:19
|
I mean errors of the following form: Invalid read of size x... Address is n - y bytes inside a block of size n... =20 - where y < x Can this sort of error be the result of some compiler optimization/bug? I get a huge number of those for some libraries we use. --partial-loads-ok=3Dyes doesn't help. (Perhaps I misunderstood the term "partial load".) Thanks, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Nicholas Nethercote Sent: Monday, October 17, 2005 9:24 PM To: Tom Hughes Cc: val...@li... Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly compared to purify On Mon, 17 Oct 2005, Tom Hughes wrote: >> There is one issue though: It looks like Valgrind reports partial loads >> as errors by default. I think this shouldn't be the default behavior. > > Actually valgrind doesn't report any loads as errors - it only > reports an error when you use an undefined value in a way that > would effect the result of the program. In other words when a > conditional jump depends on it or you use it as a pointer and > read or write through that pointer. > > It tracks definedness at bit level, so a partial load will mark > some bits as defined and leaves others alone. If you then later > use one of the undefined bits it will complain. > > There are edge cases where it thinks a bit is used when it isn't > really but they are rare. > > I think you need to explain what you mean more fully. I think he's referring to the --partial-loads-ok option, but it's set to true by default (at least, that's what "valgrind -h" says). Nick ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Scott L. <sc...@sw...> - 2005-10-17 19:33:47
|
Valgrind 3.0.1 erroneously reports an error ("Conditional jump or move
depends on uninitialised value(s)") on the if-statements of both of the
following code snippets (compiled with GCC 3.2.3, no optimization):
int main()
{
int uninit;
int two = 2;
uninit *= two;
if(!(uninit & 1)) // there should be no error here
{
printf("Hello, world!\n");
}
return 0;
}
-----
int main()
{
int uninit;
uninit ^= uninit;
if(!(uninit & 1)) // there should be no error here
{
printf("Hello, world!\n");
}
return 0;
}
Scott
|
|
From: Nick L. <ni...@io...> - 2005-10-17 19:32:31
|
Hi
> Seriously now, my experience with Valgrind has been to the contrary.
> Sure, its tempting to dismiss error messages as false alarms. But so
> far, Valgrind was right about every error that I took the time to
> investigate carefully. You can't blame Valgrind for reporting cases of
> deliberate use of un-initialized values (and I've seen some of those).
Quite agree on the last point, which is why we weren't. As another poster
said, it's actually quite common in comms related code for there to be
valid UMR's.
Based on past good experiences I was surprised just how way off valgrind
was, hence the query really, and the reports of a function return value
being unintialised when it wasn't was particularly frustrating. I haven't
determined the syntax to suppress specific lines yet (can this even be
done?), so had to suppress the entire function which could have masked
genuine problems. As I said, valgrind has certainly been right on some C
projects in the past, so I didn't know what was up in this case. Purify
was spot on though.
I don't like to compare great free opensource efforts against highly
expensive commercial ones, but as well as an overhaul of the suppressions
mechanism, two features that really would be nice, and apologies if these
exist already, would be identifying variable names from addresses wherever
possible, and showing where freed memory was allocated from. In the
following case:
int main()
{
char* buf = malloc(5);
int i,j = 0;
buf[7] = 0;
free(buf);
buf[3] = 12;
return i + j;
}
Valgrind correctly reports the problems, although incorrectly says that
buf[7] is a write 2 bytes beyond the end of the memory when it's 3 bytes
beyond. The uninitialised value in the return is caught, however which
variable is at fault is not identified. Where the freed memory was
allocated from is also not shown.
In contrast, purify identifies correctly the write 3 bytes beyond the end
of the block, shows where the freed memory was allocated from, and most
crucially indicates that the problem in the return is with variable i. Of
course it's clear in this case, but in general, the symbolic
identification can be very useful in locating problems in compound
expressions.
VG
==9484== Invalid write of size 1
==9484== at 0x8048389: main (x.c:8)
==9484== Address 0x1BA5A02F is 2 bytes after a block of size 5 alloc'd
==9484== at 0x1B8FEA35: malloc (vg_replace_malloc.c:149)
==9484== by 0x8048375: main (x.c:5)
==9484==
==9484== Invalid write of size 1
==9484== at 0x80483A0: main (x.c:12)
==9484== Address 0x1BA5A02B is 3 bytes inside a block of size 5 free'd
==9484== at 0x1B8FF548: free (vg_replace_malloc.c:235)
==9484== by 0x8048396: main (x.c:10)
==9484==
==9484== Syscall param exit_group(exit_code) contains uninitialised byte(s)
==9484== at 0x1B9CC3F7: _Exit (in /lib/libc-2.3.2.so)
==9484== by 0x1B93391E: __libc_start_main (in /lib/libc-2.3.2.so)
==9484== by 0x80482CC: ??? (start.S:81)
Purify
**** Purify instrumented ./x (pid 9594) ****
ABW: Array bounds write:
* This is occurring while in:
main [x.c:8]
__libc_start_main [libc.so.6]
_start [crt1.o]
* Writing 1 byte to 0x80b4927 in the heap.
* Address 0x80b4927 is 3 bytes past end of a malloc'd block at 0x80b4920
of 5 bytes.
* This block was allocated from:
malloc [rtlib.o]
main [x.c:5]
__libc_start_main [libc.so.6]
_start [crt1.o]
**** Purify instrumented ./x (pid 9594) ****
FMW: Free memory write:
* This is occurring while in:
main [x.c:12]
__libc_start_main [libc.so.6]
_start [crt1.o]
* Writing 1 byte to 0x80b4923 in the heap.
* Address 0x80b4923 is 3 bytes into a freed block at 0x80b4920 of 5 bytes.
* This block was allocated from:
malloc [rtlib.o]
main [x.c:5]
__libc_start_main [libc.so.6]
_start [crt1.o]
* There have been 0 frees since this block was freed from:
free [rtlib.o]
main [x.c:10]
__libc_start_main [libc.so.6]
_start [crt1.o]
**** Purify instrumented ./x (pid 9594) ****
UMR: Uninitialized memory read:
* This is occurring while in:
main [x.c:14]
__libc_start_main [libc.so.6]
_start [crt1.o]
* Reading 4 bytes from 0xbfffeea0 on the stack.
* Address 0xbfffeea0 is local variable "i" in function main.
Nick
|
|
From: Nicholas N. <nj...@cs...> - 2005-10-17 19:24:06
|
On Mon, 17 Oct 2005, Tom Hughes wrote: >> There is one issue though: It looks like Valgrind reports partial loads >> as errors by default. I think this shouldn't be the default behavior. > > Actually valgrind doesn't report any loads as errors - it only > reports an error when you use an undefined value in a way that > would effect the result of the program. In other words when a > conditional jump depends on it or you use it as a pointer and > read or write through that pointer. > > It tracks definedness at bit level, so a partial load will mark > some bits as defined and leaves others alone. If you then later > use one of the undefined bits it will complain. > > There are edge cases where it thinks a bit is used when it isn't > really but they are rare. > > I think you need to explain what you mean more fully. I think he's referring to the --partial-loads-ok option, but it's set to true by default (at least, that's what "valgrind -h" says). Nick |
|
From: Tom H. <to...@co...> - 2005-10-17 19:06:49
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> There is one issue though: It looks like Valgrind reports partial loads
> as errors by default. I think this shouldn't be the default behavior.
Actually valgrind doesn't report any loads as errors - it only
reports an error when you use an undefined value in a way that
would effect the result of the program. In other words when a
conditional jump depends on it or you use it as a pointer and
read or write through that pointer.
It tracks definedness at bit level, so a partial load will mark
some bits as defined and leaves others alone. If you then later
use one of the undefined bits it will complain.
There are edge cases where it thinks a bit is used when it isn't
really but they are rare.
I think you need to explain what you mean more fully.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 18:43:34
|
I know of a memory checker that never ever gives you a single false
positive, and is included in all Linux distributions. Here is the
usage:
ls <program name>
Seriously now, my experience with Valgrind has been to the contrary.
Sure, its tempting to dismiss error messages as false alarms. But so
far, Valgrind was right about every error that I took the time to
investigate carefully. You can't blame Valgrind for reporting cases of
deliberate use of un-initialized values (and I've seen some of those).
There is one issue though: It looks like Valgrind reports partial loads
as errors by default. I think this shouldn't be the default behavior.
Regards,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Nick
Lindridge
Sent: Monday, October 17, 2005 4:22 PM
To: val...@li...
Subject: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
Hi all
Looking for any hints on why valgrind may be reporting hundreds of bogus
errors in some C++/C code, compared to purify working and reporting
flawlessly on the same code on the same machine.
The code was tested with both older valgrinds and the latest valgrind 3
on
a code base with openssh, libssh2, and other code, and has been giving
not
only vast numbers of errors, but plenty of errors reports that are
deomonstrably bogus. It took a couple of hours to produce a suppressions
file that would suppress enough to be able to see any possible genuine
errors, but even then, the genuine bugs in libssh2, for example, weren't
caught as far as we could see. Only purify gave the true picture,
finding
the problems in libssh2, and only a few other UMR reports related to
openssh crypto functions that are actually ok.
I know from previous experience that valgrind can be good, so does
anyone
have any ideas why in this case it was so disastrously off base? Files
were optimised -O0 as recommended, and tested both on a 2.2 kernel and
2.95.3 (with an old valgrind), and the latest valgrind with 2.4.20-31.9
and gcc 3.2.2.
One simple failing example was:
n =3D libssh2_channel_read(ch->channel_ptr(), buf, bufsize - 1);
if (n < 0) {
//
}
where n was sometimes reported as being uninitialised on the
conditional.
This was provably incorrect, and verifed both by purify and having a
correct return result, with all code paths inside the function
initialising the return value, and with values that were themselves
always
initialised, so there was no propagation of uninitialised data. Some of
the libssh code was also rewritten to move automatics defined in
innerblocks to the outer most level, just in case overlapping autos were
in anyway a problem, but as expected, this made no difference.
Sorry if I missed something such as valgrind not working with C++
binaries, but I don't believe that there's any problem there.
Any suggestions to try are welcome!
Nick
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads,
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: <ape...@ni...> - 2005-10-17 17:34:06
|
On Thu, Oct 13, 2005 at 07:51:21PM +0530, Jaskaran Singh wrote: > Does valgrind provide a means of selectively turning heap checking ON and OFF programmatically ? > > Something like: > > HeapChecker.start(); > doSomething(); > HeapChecker.stop(); > > so that the generated report contains leaks, if any, in doSomething(); I am looking to integrate valgrind with my unit test framework but I do not want the complete test harness to run under valgrind as that can be prohibitive. I don't think valgrind lets you do specifically that. We made it work with WvStreams unit tests, however, by comparing the *number* of "definitely lost" leaks before and after doSomething() by using the valgrind API function that checks for and feeds you that number. Then we consider it a failed unit test if the number has changed. Note that "still reachable" and "possibly lost" blocks are meaningless except at the very end of the program (think global constructors), so we don't use those numbers. The API calls you suggest might still be useful if added to valgrind: allocated blocks could be tagged with an "I care about this block" flag. If they were allocated after a HeapChecker.stop(), we don't care about this block, so it won't be counted when checking the final memory leak count. However, in my experience, it's best to just fix all your memory leaks: it's not so great if your unit test framework (outside of doSomething()) is itself leaking memory. Have fun, Avery |
|
From: Nicholas N. <nj...@cs...> - 2005-10-17 15:16:32
|
On Mon, 17 Oct 2005, Nick Lindridge wrote: > Looking for any hints on why valgrind may be reporting hundreds of bogus > errors in some C++/C code, compared to purify working and reporting > flawlessly on the same code on the same machine. > > The code was tested with both older valgrinds and the latest valgrind 3 on > a code base with openssh, libssh2, and other code, The only thing I can think of is that I think SSL (which ssh uses?) deliberately uses uninitialised memory as a source of entropy for some random number generator, or something like that. So it's possible that these are propagating throughout the program in various ways. If it is the case, the way to fix it would be to add client requests to SSL (eg. VALGRIND_MAKE_READABLE) to mark the uninitialised memory as being initialised. Nick |
|
From: Nick L. <ni...@io...> - 2005-10-17 14:22:26
|
Hi all
Looking for any hints on why valgrind may be reporting hundreds of bogus
errors in some C++/C code, compared to purify working and reporting
flawlessly on the same code on the same machine.
The code was tested with both older valgrinds and the latest valgrind 3 on
a code base with openssh, libssh2, and other code, and has been giving not
only vast numbers of errors, but plenty of errors reports that are
deomonstrably bogus. It took a couple of hours to produce a suppressions
file that would suppress enough to be able to see any possible genuine
errors, but even then, the genuine bugs in libssh2, for example, weren't
caught as far as we could see. Only purify gave the true picture, finding
the problems in libssh2, and only a few other UMR reports related to
openssh crypto functions that are actually ok.
I know from previous experience that valgrind can be good, so does anyone
have any ideas why in this case it was so disastrously off base? Files
were optimised -O0 as recommended, and tested both on a 2.2 kernel and
2.95.3 (with an old valgrind), and the latest valgrind with 2.4.20-31.9
and gcc 3.2.2.
One simple failing example was:
n = libssh2_channel_read(ch->channel_ptr(), buf, bufsize - 1);
if (n < 0) {
//
}
where n was sometimes reported as being uninitialised on the conditional.
This was provably incorrect, and verifed both by purify and having a
correct return result, with all code paths inside the function
initialising the return value, and with values that were themselves always
initialised, so there was no propagation of uninitialised data. Some of
the libssh code was also rewritten to move automatics defined in
innerblocks to the outer most level, just in case overlapping autos were
in anyway a problem, but as expected, this made no difference.
Sorry if I missed something such as valgrind not working with C++
binaries, but I don't believe that there's any problem there.
Any suggestions to try are welcome!
Nick
|
|
From: Jitendra <jit...@as...> - 2005-10-17 12:21:35
|
Thanks a lot for helping me.and one more thing, actually I am new to these library, so could you please help me out, How to test the whole project.. Jiten |
|
From: Tom H. <to...@co...> - 2005-10-17 09:05:38
|
In message <0IO...@vm...>
jit...@as... wrote:
> I have downloaded your current release (valgrind-3.0.1) .I am using
> Mandrake 9.2 with gcc 3.3.1 and I got some error while running "make". So
> could you please help me.
You need to install the static C library development components. They
are probably in an RPM called glibc-static-devel or some such.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Igmar P. <mai...@jd...> - 2005-10-17 09:04:53
|
Hi, > I have downloaded your current release (valgrind-3.0.1) .I am using > Mandrake 9.2 with gcc 3.3.1 and I got some error while running "make". So > could you please help me. > > I am attaching error log file with these mail, so please look at it. > Revert back as soon as possible As a quick search through the archives would have told you : Install the static libc libraries (glibc-static-x.x.x.i386.rpm). Igmar |
|
From: Nicholas N. <nj...@cs...> - 2005-10-15 16:50:21
|
On Thu, 13 Oct 2005, Jaskaran Singh wrote: > Does valgrind provide a means of selectively turning heap checking ON > and OFF programmatically ? > > Something like: > > HeapChecker.start(); > doSomething(); > HeapChecker.stop(); > > so that the generated report contains leaks, if any, in doSomething(); I > am looking to integrate valgrind with my unit test framework but I do > not want the complete test harness to run under valgrind as that can be > prohibitive. You can invoke the leak checker at any time by using the VALGRIND_DO_LEAK_CHECK and VALGRIND_COUNT_LEAKS client requests. See 3.7 in the manual. --- On this note: we regularly get questions like this from Valgrind users who want to use Valgrind for unit testing. It would be great to have something in the manual and/or the FAQ about how to set this up. If someone who has set up such a system is willing to write a short description of how it works, that would be very useful. Nick |
|
From: Yin, H. <hu...@me...> - 2005-10-14 18:45:22
|
Hi, =20 I noticed that there are some statements on valgrind website about no valgrind support for windows. Does it make a difference if my windows objects compiled from MinGW gcc? =20 Is there more updated wine-variant valgrind than valgrind 20031012-wine <http://valgrind.org/downloads/valgrind-20031012-wine.tar.bz2> package? Has anyone tried this with recent WINE release? =20 Thanks, --Hui =20 |
|
From: Rak <ra...@ho...> - 2005-10-14 17:51:40
|
Tom Hughes <tom <at> compton.nu> writes: > > In message <loom.20051014T163455-681 <at> post.gmane.org> > rak_25 <at> hotmail.com wrote: > > > Valgrind does not crash but it gives me this error messgae and abort the > > program. Is this a bug or I am doing something wrong? > > It's a bug - specifically an instruction that is not supported. Please > raise a bug for this on the bug tracker. > > > vex amd64->IR: unhandled instruction bytes: 0xF 0xAD 0xC2 0xD3 > > That's "SHRD %cl,Gv,Ev" which the amd64 engine doesn't support currently. > > Tom > Submited Bug 114412: vex amd64->IR: unhandled instruction bytes: 0xF 0xAD 0xC2 0xD3 Thanks, Rak |
|
From: John R.
|
> vex amd64->IR: unhandled instruction bytes: 0xF 0xAD 0xC2 0xD3 shrd %cl,%eax,%edx # 64-bit shift: graphics or crypto, etc. roll %cl, ... -- |
|
From: Tom H. <to...@co...> - 2005-10-14 15:00:40
|
In message <loo...@po...>
ra...@ho... wrote:
> Valgrind does not crash but it gives me this error messgae and abort the
> program. Is this a bug or I am doing something wrong?
It's a bug - specifically an instruction that is not supported. Please
raise a bug for this on the bug tracker.
> vex amd64->IR: unhandled instruction bytes: 0xF 0xAD 0xC2 0xD3
That's "SHRD %cl,Gv,Ev" which the amd64 engine doesn't support currently.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rak <ra...@ho...> - 2005-10-14 14:49:47
|
Hi, Valgrind does not crash but it gives me this error messgae and abort the program. Is this a bug or I am doing something wrong? Thanks, Rak xeon%uname -a Linux xeon 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux xeon%valgrind --tool=memcheck --num-callers=30 ./pro ==14886== Memcheck, a memory error detector. ==14886== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==14886== Using LibVEX rev 1419, a library for dynamic binary translation. ==14886== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==14886== Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. ==14886== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14886== For more details, rerun with: -v ==14886== ==14886== Warning: set address range perms: large range 257616336, a 0, v 1 ==14886== Warning: set address range perms: large range 188918656, a 0, v 1 ==14886== Warning: set address range perms: large range 626458864, a 0, v 1 . . . ==14886== Warning: set address range perms: large range 257616336, a 0, v 1 **NOTE - REALLOCATING MEMORY vex amd64->IR: unhandled instruction bytes: 0xF 0xAD 0xC2 0xD3 ==14886== Your program just tried to execute an instruction that Valgrind ==14886== did not recognise. This might be because your program has a bug ==14886== and erroneously jumped to a non-code location. If you are running ==14886== Memcheck, you might have just seen a warning about a bad jump, ==14886== which is a good indication that this is so. Or it might be ==14886== because the instruction is unimplemented in Valgrind; if you ==14886== think this is the case, or you are not sure, please let us know. ==14886== ==14886== Process terminating with default action of signal 4 (SIGILL) ==14886== Illegal opcode at address 0x2525F67 ==14886== at 0x2525F67: _normal64 (in /u/xeon/working/pro) ==14886== ==14886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 5) ==14886== malloc/free: in use at exit: 2,302,994,016 bytes in 878,618 blocks. ==14886== malloc/free: 879,341 allocs, 723 frees, 2,303,707,200 bytes allocated. |