|
From: Tom H. <to...@co...> - 2008-08-01 12:13:46
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Friday 01 August 2008 13:50, Ashley Pittman wrote:
>> On Fri, 2008-08-01 at 14:42 +0300, Yeshurun, Meir wrote:
>> > Does the following code mean a program is broken?
>> >
>> > if (p1 < p2)
>> > ...
>> > else
>> > ...
>>
>> It's probably valid c but I'm struggling to think of anything other
>> than obscure cases where it would be considered a good idea,
>> particularly when using < or > and not ==.
>
> Well, for example, imagine having a binary tree with pointer keys
> (we have lots of them in V, for example) then looking up, inserting,
> etc, in the tree will naturally involve comparing pointers, and that's
> fine.
Technically that is I believe in violation of the C standard, but on
a machine with a flat memory model like a linux system it will work so
long as you expect any particular meaning from it beyond a way of
sorting/searching a set of pointers.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2008-08-01 12:45:40
|
On Friday 01 August 2008 14:13, Tom Hughes wrote: > In message <200...@ac...> > Julian Seward <js...@ac...> wrote: > > > On Friday 01 August 2008 13:50, Ashley Pittman wrote: > >> On Fri, 2008-08-01 at 14:42 +0300, Yeshurun, Meir wrote: > >> > Does the following code mean a program is broken? > >> > > >> > if (p1 < p2) > >> > ... > >> > else > >> > ... > >> > >> It's probably valid c but I'm struggling to think of anything other > >> than obscure cases where it would be considered a good idea, > >> particularly when using < or > and not ==. > > > > Well, for example, imagine having a binary tree with pointer keys > > (we have lots of them in V, for example) then looking up, inserting, > > etc, in the tree will naturally involve comparing pointers, and that's > > fine. > > Technically that is I believe in violation of the C standard, Yes .. I did wonder about that after you mentioned about the comparisons between different arrays. > but on > a machine with a flat memory model like a linux system it will work so > long as you expect any particular meaning from it beyond a way of > sorting/searching a set of pointers. s/you expect/you don't expect/g ? Which is fine; I don't expect that. J |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 12:20:10
|
Okay, I'm not complaining.
Anyway, the good news is that this wasn't a bug in Valgrind or anything
like that, and it is rare.
I've been using Valgrind for 3 years and this was the first time it
couldn't help me find the bug.
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Friday, August 01, 2008 3:14 PM
To: val...@li...
Subject: Re: [Valgrind-users] "glibc detected..." error
In message
<D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> If so, Memcheck should be able to report it.
Memcheck is not a "find every bug in your program" tool, it finds
specific classes of bug, and that is not one of them.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
|
|
From: dizzy <di...@ro...> - 2008-08-01 12:41:50
|
On Friday 01 August 2008 15:20:10 Yeshurun, Meir wrote: > I've been using Valgrind for 3 years and this was the first time it > couldn't help me find the bug. Almost all stack buffer overflow bugs are not detected by valgrind (at least they weren't then) because from valgrind point of view you access valid memory (just not through a valid pointer to it but when you run valgrind it cannot know what variables you have and what are they supposed to do, that's a detail the compiler knows about which is why buffer overflow memory debuggers generally come as patches for the compiler). If in a program you REALLY do need to compare unrelated (valid and/or null) pointers if you use C++ you could use std::less functor to do it since ISO C++ guarantees that std::less can be used to compare unrelated pointers (which means you can use std::set/std::map of pointer types just fine). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST |
|
From: Julian S. <js...@ac...> - 2008-08-01 12:53:16
|
On Friday 01 August 2008 14:06, Yeshurun, Meir wrote: > > So what you're saying is even Valgrind's code itself contains the pointer > comparisons I'm talking about. Yes. Although mostly for Valgrind's internal data structures; nothing directly to do with the program you happen to be running on Valgrind. > If the pointer values change, > the behavior of the program will change, No. Mostly these pointers are merely used as keys in binary trees. So if the pointer values change, we will still be able to do lookups, inserts, etc, in the trees, and the results will be unchanged. > and a memory violation will not > be reproduced. Umm, all I am saying is that (1) it's sometimes OK to compare pointers, and (2) as an example, that happens a lot in Valgrind's internal data structures, via the types OSet and WordFM. J |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 13:03:08
|
I was trying to say that it's normal for a program's behavior to depend on pointer values, therefore a memory corruption might not be reproduced when running under Valgrind because it changes pointer values (much more than any native randomization if such randomization indeed exists as Ashley claims) Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Friday, August 01, 2008 3:45 PM To: Yeshurun, Meir Cc: Ashley Pittman; val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error On Friday 01 August 2008 14:06, Yeshurun, Meir wrote: > > So what you're saying is even Valgrind's code itself contains the pointer > comparisons I'm talking about. Yes. Although mostly for Valgrind's internal data structures; nothing directly to do with the program you happen to be running on Valgrind. > If the pointer values change, > the behavior of the program will change, No. Mostly these pointers are merely used as keys in binary trees. So if the pointer values change, we will still be able to do lookups, inserts, etc, in the trees, and the results will be unchanged. > and a memory violation will not > be reproduced. Umm, all I am saying is that (1) it's sometimes OK to compare pointers, and (2) as an example, that happens a lot in Valgrind's internal data structures, via the types OSet and WordFM. J --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: dizzy <di...@ro...> - 2008-08-01 13:53:34
|
On Friday 01 August 2008 15:57:55 Yeshurun, Meir wrote: > I was trying to say that it's normal for a program's behavior to depend > on pointer values, therefore a memory corruption might not be reproduced > when running under Valgrind because it changes pointer values (much more > than any native randomization if such randomization indeed exists as > Ashley claims) Are you sure about that? There is no guarantee in the C or C++ standards about pointer values (other than the null pointer which is obtained by converting the 0 literal value to pointer but notice this does not mean that the pointer value representation for the null pointer has all the bits 0). A program that depends on specific pointer values for "correct behavior" is not a conforming program as far as I can imagine. Can you give an example of such a conforming program? -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 14:05:04
|
I'm talking about a program whose *internal* behavior depends on pointer values. Can you imagine that? Now, suppose a memory corruption occurs only when a set of pointer values cause the internal flow of control to go a certain way. Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of dizzy Sent: Friday, August 01, 2008 4:53 PM To: val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error On Friday 01 August 2008 15:57:55 Yeshurun, Meir wrote: > I was trying to say that it's normal for a program's behavior to depend > on pointer values, therefore a memory corruption might not be reproduced > when running under Valgrind because it changes pointer values (much more > than any native randomization if such randomization indeed exists as > Ashley claims) Are you sure about that? There is no guarantee in the C or C++ standards about pointer values (other than the null pointer which is obtained by converting the 0 literal value to pointer but notice this does not mean that the pointer value representation for the null pointer has all the bits 0). A program that depends on specific pointer values for "correct behavior" is not a conforming program as far as I can imagine. Can you give an example of such a conforming program? -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 14:34:27
|
> For implementation defined code paths probably, not very portable tho. I disagree. Even Julian's simple example of a binary tree of pointers is an example of such code. Suppose your binary tree has a bug. -----Original Message----- From: dizzy [mailto:di...@ro...] Sent: Friday, August 01, 2008 5:27 PM To: Yeshurun, Meir Subject: Re: [Valgrind-users] "glibc detected..." error On Friday 01 August 2008 17:04:59 you wrote: > I'm talking about a program whose *internal* behavior depends on pointer > values. Can you imagine that? For implementation defined code paths probably, not very portable tho. > Now, suppose a memory corruption occurs only when a set of pointer > values cause the internal flow of control to go a certain way. Sure, I usually call these heisenbugs, they show up in a normal environment and they don't show up anymore with valgrind (or gdb, although usually they do show up at least with gdb which does not change drastically the memory layout like valgrind does). You usually can't debug these problems with valgrind and other methods are required (it helps much sometimes if instead of running valgrind on the unmodified executable you call upon valgrind engine verification routines at key points in your code to check for some things). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |