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: Florian W. <fw...@de...> - 2005-10-18 11:44:11
|
* Julian Seward: > It would be interesting to know if building a system which *always* > correctly differentiates uninitialised vs initialised bits is > equivalent to solving the halting problem (viz, undecideable). > I suspect so. Statically, for languages like C? Sure. But dynamically, during execution, it should be possible. |
|
From: Florian W. <fw...@de...> - 2005-10-18 11:42:52
|
* Tom Hughes: > He is testing the bottom bit so the result of the test is perfectly > well defined No it's not. The compiler may have performed some transformation which changes the bit pattern because it is undefined as far it is concerned. > - one of valgrinds strengths is that it does bit level tracking of > defined values not byte level. Sure, but the C compiler doesn't. It might make sense to fix valgrind's MUL implementaton, but this C code is a poor test case. |
|
From: Jaskaran S. <jas...@pe...> - 2005-10-18 10:21:48
|
Thanks people. The client request mechanism solves my problem for now. ~Jas ----- Original Message ----- From: <ape...@ni...> To: "Jaskaran Singh" <jas...@pe...> Cc: <val...@li...> Sent: Thursday, October 13, 2005 8:45 PM Subject: Re: [Valgrind-users] Valgrind API interface > 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: Yeshurun, M. <mei...@in...> - 2005-10-18 10:14:20
|
Thanks! :)
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Tuesday, October 18, 2005 12:06 PM
To: Yeshurun, Meir
Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
Try this. In mc_main.c find mc_LOADVn_slow() and in particular
this:
if (n_addrs_bad > 0)
MAC_(record_address_error)( VG_(get_running_tid)(), a, szB, False
);
change it to
if (n_addrs_bad =3D=3D szB)
MAC_(record_address_error)( VG_(get_running_tid)(), a, szB, False
);
This effectively reinstates the partial-loads-ok hack.
J
On Tuesday 18 October 2005 01:29, you wrote:
> That's the only requirement I can't satisfy :). The libraries I'm
> talking about are from external vendors.
>
> Meir
>
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Tuesday, October 18, 2005 2:25 AM
> To: Yeshurun, Meir
> Cc: val...@li...
> Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing
terribly
> compared to purify
>
> > At least in some of the cases, it looks indeed like a fast memcpy
>
> since
>
> > the top-most function in the stack trace is named my_strdup. So I
>
> guess
>
> > the only option is to add a suppression, right?
>
> Can you rewrite my_strdup so it doesn't fall off the end of arrays?
> You should be able to do that without a loss of performance using
> standard loop vectorisation techniques. The only requirement is
> access to the source.
>
> J
|
|
From: Tom H. <to...@co...> - 2005-10-18 10:08:13
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>> > As far as I can tell, the whole of uninit is undefined, so is the result
>> > of the multiplication.
>> >
>> >> if(!(uninit & 1)) // there should be no error here
>> >> {
>> >
>> > uninit still contains random data. Why shouldn't it give errors ?
>>
>> He is only looking at the lowest bit and as he has doubled it that
>> bit is guaranteed to be zero and well defined.
>
> The rest of the bits aren't defined. Since you can't address anything less
> then a byte, it should give errors on these kind of operations if you ask
> me.
He is testing the bottom bit so the result of the test is perfectly
well defined - one of valgrinds strengths is that it does bit level
tracking of defined values not byte level.
>> Multiplying by two is after equivalent to a left shift by one and
>> such a shift is guaranteed to shift in a zero and hence make the
>> bottom bit well defined.
>
> You still take at least 8 bits when doing the and operation. From a
> theoretical point it makes sense and you're right. From a logical sense
> (partial) garbage in equals garbage out :)
The process may and 8 bits or 32 bits or 64 bits but only one of them
affects the result of the operation.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-18 09:59:23
|
> > well, the xor testcase failure is interesting, because that is indeed a > > real bug (we used to do defined-ness tracking at bitlevel for xor, while > > we never did that for multiplies so far). > > There is (or was) a special case for xor of a register with itself > which caused memcheck to consider the whole thing as defined because > compilers use that trick to generate zero. That case is still there for x86 and amd64. I suspect the reason why it doesn't work here is because program was compiled with no optimisation and so gcc is not emitting 'xorl %reg,%reg' but some other longer sequence which the case doesn't catch. It has friends too now: the MySQL folks discovered that gcc sometimes produces 'sbbl %reg,%reg' which gets the carry flag into %reg and doesn't depend on its previous value. So that is handled similarly. > Other than that I think xor just marks an output bit as defined if > both input bits are defined as the result of xor always depends on > both inputs. Yeh .. I can't think of a more accurate definedness rule which is correct, unfortunately. --- Something I should have mentioned earlier: a good introduction to the definedness analysis in memcheck is available at http://www.valgrind.org/docs/memcheck2005.pdf. J |
|
From: Igmar P. <mai...@jd...> - 2005-10-18 09:49:43
|
> > As far as I can tell, the whole of uninit is undefined, so is the result
> > of the multiplication.
> >
> >> if(!(uninit & 1)) // there should be no error here
> >> {
> >
> > uninit still contains random data. Why shouldn't it give errors ?
>
> He is only looking at the lowest bit and as he has doubled it that
> bit is guaranteed to be zero and well defined.
The rest of the bits aren't defined. Since you can't address anything less
then a byte, it should give errors on these kind of operations if you ask
me.
> Multiplying by two is after equivalent to a left shift by one and
> such a shift is guaranteed to shift in a zero and hence make the
> bottom bit well defined.
You still take at least 8 bits when doing the and operation. From a
theoretical point it makes sense and you're right. From a logical sense
(partial) garbage in equals garbage out :)
Regards,
Igmar
|
|
From: Tom H. <to...@co...> - 2005-10-18 09:25:12
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Tuesday 18 October 2005 00:48, Julian Seward wrote:
>
>> That said .. if the cases you show are real problems in real code,
>> and not just example test cases, then I am interested in investigating
>> further.
>
> well, the xor testcase failure is interesting, because that is indeed a real
> bug (we used to do defined-ness tracking at bitlevel for xor, while we never
> did that for multiplies so far).
There is (or was) a special case for xor of a register with itself
which caused memcheck to consider the whole thing as defined because
compilers use that trick to generate zero.
Other than that I think xor just marks an output bit as defined if
both input bits are defined as the result of xor always depends on
both inputs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-10-18 09:17:50
|
On Tuesday 18 October 2005 00:48, Julian Seward wrote: > That said .. if the cases you show are real problems in real code, > and not just example test cases, then I am interested in investigating > further. well, the xor testcase failure is interesting, because that is indeed a real bug (we used to do defined-ness tracking at bitlevel for xor, while we never did that for multiplies so far). Dirk |
|
From: Tom H. <to...@co...> - 2005-10-18 07:44:11
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>> int main()
>> {
>> int uninit;
>
> uninit is undefined here.
>
>> int two = 2;
>>
>> uninit *= two;
>
> this is uninit = uninit * 2;
>
> As far as I can tell, the whole of uninit is undefined, so is the result
> of the multiplication.
>
>> if(!(uninit & 1)) // there should be no error here
>> {
>
> uninit still contains random data. Why shouldn't it give errors ?
He is only looking at the lowest bit and as he has doubled it that
bit is guaranteed to be zero and well defined.
Multiplying by two is after equivalent to a left shift by one and
such a shift is guaranteed to shift in a zero and hence make the
bottom bit well defined.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Igmar P. <mai...@jd...> - 2005-10-18 07:31:24
|
> int main()
> {
> int uninit;
uninit is undefined here.
> int two = 2;
>
> uninit *= two;
this is uninit = uninit * 2;
As far as I can tell, the whole of uninit is undefined, so is the result
of the multiplication.
> if(!(uninit & 1)) // there should be no error here
> {
uninit still contains random data. Why shouldn't it give errors ?
Regards,
Igmar
|
|
From: Christopher T. <Chr...@pa...> - 2005-10-18 00:41:48
|
This has been talked around already, but i wanted to be very clear: the =
example program given here is fundamentally incorrect. It is perfectly =
valid for a conforming compiler to emit code that causes this program to =
segfault on the access to *(int*)(a+9).
(This is done explicitly sometimes in debug allocators -- the requested =
block is located at the end of a VM page, and the following page is =
marked unreadable/unwritable.)
--
Christopher Tate
chr...@pa...
> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...]On Behalf Of
> Yeshurun, Meir
> Sent: Monday, October 17, 2005 1:55 PM
> To: Tom Hughes
> Cc: val...@li...
> Subject: RE: [Valgrind-users] User error? - Valgrind 3=20
> failing terribly
> compared to purify
>=20
>=20
> 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=20
> failing terribly
> compared to purify
>=20
> In message
> <942...@ha...rp.i
> ntel.com>
> "Yeshurun, Meir" <mei...@in...> wrote:
>=20
> > There is one issue though: It looks like Valgrind reports partial
> loads
> > as errors by default. I think this shouldn't be the default=20
> behavior.
>=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
> --=20
> Tom Hughes (to...@co...)
> http://www.compton.nu/
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,=20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>=20
|
|
From: Nick L. <ni...@io...> - 2005-10-18 00:38:13
|
Hi > For that set, it leans in the direction of reporting an error even when > one doesn't exist. The reason is simple: you can usually make it shut up > by adding a few unnecessary initialisations in the right place. The > KDE folks did that, I believe, at some point in the KDE 3.0 line. > Once you've made it shut up, you at least know that your program is > now (probably) safe against use of uninitialised values. Thanks for the response Julian. You're quite correct, and that's the right approach. e.g. the RAND_bytes() function generates errors on the buffer it's filling in, so just memset() the buffer first. No problem with that at all, and a totally standad technique in these cases. The problem as much as anything though was with the value returned from the function that I mentioned in the first post. No amount of assigning to the variable being returned would stop valgrind from reporting the returned value in some cases as uninitialised, and preinitialising to zero the variable accepting the returned value prior to the assignment made no difference either. There were also quite a few reports of memory that wasn't in a known area, i.e. not stack'd, alloc'd etc., but where there was actually no problem at all, and as far as I could tell, a genuine error of a free memory write in libssh2 wasn't caught. On other large projects with the same compiler etc. it's done well though, so who knows? I was surprised, hence the post :) On the reply to the offset issue, there appears to be a confusion over offsets vs. byte counts. In the case of &buf[7], where buf is a buffer of 5 bytes, Purify is correct to say that &buf[7] is 3 bytes beyond the end as it's reporting the byte count. valgrinds report of 2 is really the byte offset, although worded as a count, but if interpreted as an offset then also correct as if we've set a variable 'end' to (beyond) the end of the buffer, &end[2] (offset 2) would be &buf[7] (the 3rd byte relative to the end). Nick |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-18 00:30:20
|
That's the only requirement I can't satisfy :). The libraries I'm talking about are from external vendors. Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...]=20 Sent: Tuesday, October 18, 2005 2:25 AM To: Yeshurun, Meir Cc: val...@li... Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly compared to purify > At least in some of the cases, it looks indeed like a fast memcpy since > the top-most function in the stack trace is named my_strdup. So I guess > the only option is to add a suppression, right? Can you rewrite my_strdup so it doesn't fall off the end of arrays? You should be able to do that without a loss of performance using standard loop vectorisation techniques. The only requirement is=20 access to the source. J |
|
From: Julian S. <js...@ac...> - 2005-10-18 00:23:15
|
> At least in some of the cases, it looks indeed like a fast memcpy since > the top-most function in the stack trace is named my_strdup. So I guess > the only option is to add a suppression, right? Can you rewrite my_strdup so it doesn't fall off the end of arrays? You should be able to do that without a loss of performance using standard loop vectorisation techniques. The only requirement is access to the source. J |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-18 00:03:26
|
Thanks, the whole issue of partially invalid reads and the problems with string manipulation functions is clear now (I didn't even know the two issues were related.) I guess it is safer to suppress the partial loads individually than to turn all of them off. At least in some of the cases, it looks indeed like a fast memcpy since the top-most function in the stack trace is named my_strdup. So I guess the only option is to add a suppression, right? Thanks, Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...]=20 Sent: Tuesday, October 18, 2005 1:50 AM To: val...@li... Cc: Yeshurun, Meir Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly compared to purify > I don't think the problem in this case is related to strcpy, it's > because of the weird read in the last line of the program. Oh .. my mistake. I misread the program. So then the question is .. why do you think this program is OK? After all you really are reading off the end of the array you allocated. ISO C I'm fairly sure would say that the behaviour is therefore undefined. > Anyway, isn't there a way to suppress error messages for partially > invalid reads? Not any more. Although it would be feasible to reinstate the partial-loads-ok hack, defaulted to off, I'd much prefer people to fix code which behaves like this. Do you have any further details of what this library is trying to do? Some kind of fast memcpy? J |
|
From: Julian S. <js...@ac...> - 2005-10-17 23:47:54
|
> I don't think the problem in this case is related to strcpy, it's > because of the weird read in the last line of the program. Oh .. my mistake. I misread the program. So then the question is .. why do you think this program is OK? After all you really are reading off the end of the array you allocated. ISO C I'm fairly sure would say that the behaviour is therefore undefined. > Anyway, isn't there a way to suppress error messages for partially > invalid reads? Not any more. Although it would be feasible to reinstate the partial-loads-ok hack, defaulted to off, I'd much prefer people to fix code which behaves like this. Do you have any further details of what this library is trying to do? Some kind of fast memcpy? J |
|
From: Julian S. <js...@ac...> - 2005-10-17 23:25:17
|
> > 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. The way I think about memcheck is slightly different. Memcheck cannot exactly partition all possible programs into those which do really use uninitialised values and those which don't. But mostly it's pretty good. Nevertheless there is a set of programs which it incorrectly classifies. For that set, it leans in the direction of reporting an error even when one doesn't exist. The reason is simple: you can usually make it shut up by adding a few unnecessary initialisations in the right place. The KDE folks did that, I believe, at some point in the KDE 3.0 line. Once you've made it shut up, you at least know that your program is now (probably) safe against use of uninitialised values. The alternative is to make it not report errors from such programs. That seems more convenient, but from an absolutist perspective of detecting all possible errors (so as to enable programmers to maximise software reliability, which was the original design goal for memcheck), it seems a poor alternative. In practice the fact that large systems like Qt4 and KDE 3.X run essentially with zero complaints on memcheck leads me to believe that the strategy is a reasonable one. J |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 23:21:50
|
Compiling with that flag didn't cause the error not to be reported.
I don't think the problem in this case is related to strcpy, it's
because of the weird read in the last line of the program.
Anyway, isn't there a way to suppress error messages for partially
invalid reads? These error messages are quite frequent, and with some
libraries they appear so often it makes the log file unreadable.
Thanks,
Meir
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Tuesday, October 18, 2005 1:09 AM
To: val...@li...
Cc: Brian Crowder; Yeshurun, Meir; Tom Hughes
Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
What's happening is, gcc or glibc is doing the strcpy using 32-bit
loads/stores and so tramples off the end of the array.
Now ... unfortunately I believe I have confused everybody. Up to
and including 2.4.1, V would allow such loads from array ends without
complaint when --partial-loads-ok=3Dyes applied, which was the default.
But that was always a kludge, which I never liked -- I thought it could
miss genuine bugs like that.
When memcheck was rewritten for the 3.0 line, that hack got dumped.
The rationale was that we would intercept all such str* functions and
substitute our own non-optimised-to-hell versions. And so we do.
And most of the time that works fine.
Unfortunately:
(1) I appear not to have updated the help text, removed the flag
handler, or updated the manual. That's really bad .. sorry.
(2) The intercept trick is defeated if gcc inlines strcpy/strcmp,
which in your example I believe it will do. What happens if=20
you try again with -mno-inline-all-stringops for gcc?
J
On Monday 17 October 2005 22:02, Brian Crowder wrote:
> "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?
> >
> > #include <cstring>
> > #include <iostream>
> >
> > using namespace std;
> >
> > int main()
> > {
> > char *a =3D new char[11];
> > strcpy(a, "0123456789");
> > int b =3D *(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
>
> -------------------------------------------------------
> 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: Julian S. <js...@ac...> - 2005-10-17 23:07:28
|
What's happening is, gcc or glibc is doing the strcpy using 32-bit
loads/stores and so tramples off the end of the array.
Now ... unfortunately I believe I have confused everybody. Up to
and including 2.4.1, V would allow such loads from array ends without
complaint when --partial-loads-ok=yes applied, which was the default.
But that was always a kludge, which I never liked -- I thought it could
miss genuine bugs like that.
When memcheck was rewritten for the 3.0 line, that hack got dumped.
The rationale was that we would intercept all such str* functions and
substitute our own non-optimised-to-hell versions. And so we do.
And most of the time that works fine.
Unfortunately:
(1) I appear not to have updated the help text, removed the flag
handler, or updated the manual. That's really bad .. sorry.
(2) The intercept trick is defeated if gcc inlines strcpy/strcmp,
which in your example I believe it will do. What happens if
you try again with -mno-inline-all-stringops for gcc?
J
On Monday 17 October 2005 22:02, Brian Crowder wrote:
> "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
>
> -------------------------------------------------------
> 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: Julian S. <js...@ac...> - 2005-10-17 22:51:23
|
> 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. Just so. It would be interesting to know if building a system which *always* correctly differentiates uninitialised vs initialised bits is equivalent to solving the halting problem (viz, undecideable). I suspect so. J |
|
From: Julian S. <js...@ac...> - 2005-10-17 22:46:24
|
Sure. Nobody is claiming that memcheck gives 100.0% accurate
definedness tracking at all times. It would probably be possible
to introduce extra precision in definedness tracking to cover the
two cases you show. However, that more elaborate instrumentation
is slower, and so will slow down the 99.9% of programs which don't
exhibit these behaviours.
The real issue is, we have to draw a line somewhere between accuracy
of definedness tracking and the performance overhead. Where do you
want that line to be? What we have concentrated on is to make it
reasonably accurate for most run-of-the-mill integer code, and from
the feedback we get I think we do pretty well on the whole.
That said .. if the cases you show are real problems in real code,
and not just example test cases, then I am interested in investigating
further.
J
On Monday 17 October 2005 20:42, Scott Long wrote:
> 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
>
>
> -------------------------------------------------------
> 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: Julian S. <js...@ac...> - 2005-10-17 22:38:16
|
As a general point, the fact that Purify reports no error and V does does not necessary mean that V is wrong. In reality both systems have to approximate reality to some extent. It's not difficult to write a program with an error which Purify misses but Valgrind doesn't. It's arguable that V does more accurate value tracking than Purify and experience tends to show that, for the most part, when it complains about something it is correct. Sure, it's possible to fool it into reporting nonexistent problems re uses of uninitialised variables, but for real production code (as opposed to carefully constructed test cases) but this tends to be fairly rare. J |
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 21:56:32
|
I don't understand why that would make a difference. The array is
initialized, it doesn't matter what it contains.
Meir
-----Original Message-----
From: Eric Lauzon [mailto:eri...@ab...]=20
Sent: Monday, October 17, 2005 11:51 PM
To: Yeshurun, Meir
Subject: RE: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
shouldn't using zeroed memory be less problematic ...?
malloc/memset
new blabla =3D {0};
-elz
=20
> -----Original Message-----
> From: val...@li...=20
> [mailto:val...@li...] On Behalf=20
> Of Yeshurun, Meir
> Sent: 17 octobre 2005 17:21
> To: Brian Crowder
> Cc: val...@li...
> Subject: RE: [Valgrind-users] User error? - Valgrind 3=20
> failing terribly compared to purify
>=20
> It does make a difference.=20
>=20
> If the bytes were merely un-initialized, Valgrind should=20
> never report an error for this program. Since they are not=20
> even valid for reading/writing, Valgrind should report an=20
> error, but only if you specify --partial-loads-ok=3Dno.=20
>=20
> All of this is based on my understanding of what's written in=20
> the Valgrind user manual.
>=20
> Meir
>=20
> -----Original Message-----
> From: Brian Crowder [mailto:cr...@fi...]
> Sent: Monday, October 17, 2005 11:14 PM
> To: Yeshurun, Meir
> Cc: val...@li...
> Subject: Re: [Valgrind-users] User error? - Valgrind 3=20
> failing terribly compared to purify
>=20
>=20
> The bytes are not _only_ uninitalized, however, they are also=20
> beyond the
> end of the allocated data.=20
> (don't know if that makes a difference).
>=20
> -- Brian
>=20
> Yeshurun, Meir wrote:
> > The purpose of this little program was to do exactly that.=20
> My question
> > is why isn't the error suppressed by specifying
> --partial-loads-ok=3Dyes.
> >=20
> > Meir
> >=20
> > -----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
> >=20
> >=20
> > "XXX" is uninitialized memory. Ints are assumed to be 4-byte:
> >=20
> > a =3D { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9',
> 0,
> > XXX, XXX }
> > ((int*)a + 9) =3D { ............................................RRR,
> RRR,
> > RRR, RRR }
> >=20
> > the last two bytes being read in the int dereference are=20
> uninitialized
> > memory.
> >=20
> >=20
> > -- Brian
> >=20
> > Yeshurun, Meir wrote:
> >=20
> >>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
> >=20
> > terribly
> >=20
> >>compared to purify
> >>
> >>In message
> >>
> >=20
> >
> <942...@ha...rp.i
> ntel.com>
> >=20
> >> "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=20
> 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
> >=20
> >=20
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,=20
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>=20
|
|
From: Yeshurun, M. <mei...@in...> - 2005-10-17 21:20:55
|
It does make a difference.=20
If the bytes were merely un-initialized, Valgrind should never report an
error for this program. Since they are not even valid for
reading/writing, Valgrind should report an error, but only if you
specify --partial-loads-ok=3Dno.=20
All of this is based on my understanding of what's written in the
Valgrind user manual.
Meir
-----Original Message-----
From: Brian Crowder [mailto:cr...@fi...]=20
Sent: Monday, October 17, 2005 11:14 PM
To: Yeshurun, Meir
Cc: val...@li...
Subject: Re: [Valgrind-users] User error? - Valgrind 3 failing terribly
compared to purify
The bytes are not _only_ uninitalized, however, they are also beyond the
end of the allocated data.=20
(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=3Dyes.
>=20
> Meir
>=20
> -----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
>=20
>=20
> "XXX" is uninitialized memory. Ints are assumed to be 4-byte:
>=20
> a =3D { '0', '1', '2', '3', '4', '5', 6', '7', '8', '9',
0,
> XXX, XXX }
> ((int*)a + 9) =3D { ............................................RRR,
RRR,
> RRR, RRR }
>=20
> the last two bytes being read in the int dereference are uninitialized
> memory.
>=20
>=20
> -- Brian
>=20
> Yeshurun, Meir wrote:
>=20
>>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
>=20
> terribly
>=20
>>compared to purify
>>
>>In message
>>
>=20
>
<942...@ha...>
>=20
>> "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
>=20
>=20
>=20
|