|
From: Yeshurun, M. <mei...@in...> - 2008-07-11 11:10:55
|
Hi, First of all, I'd like to thank you - Valgrind has been rock stable and very helpful in detecting hard-to-debug memory corruptions (that's why you haven't heard from me...). Recently, we've been seeing messages like "glibc detected: corrupted double-linked list" followed by a crash. Memcheck reported absolutely no errors. Any ideas? Thanks again, Meir --------------------------------------------------------------------- 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: Michael W. <mic...@gm...> - 2008-07-11 14:22:24
|
> Recently, we've been seeing messages like "glibc detected: corrupted > double-linked list" followed by a crash. Memcheck reported absolutely no > errors. I've actually had the same problem, myself. In my case, it was an unsigned char array that was being c'allocted, passed through some functions, and modified along the way via pointer dereferencing and direct incrementation (ie: *chararray++ = '%c' ) somehow this caused the above error, most often I believe if/when the array was written past (buffer overflow) I was able to get rid of the problem by removing the c'alloc and re-engineering some code, but the general idea yah, same bug, no error in valgrind of any use... it did point me at a line of code involved in the frame-stack that triggered the error, but nothing more than a single line (no called from, etc.) |
|
From: Julian S. <js...@ac...> - 2008-07-14 10:16:17
|
> Recently, we've been seeing messages like "glibc detected: corrupted > double-linked list" followed by a crash. Memcheck reported absolutely no > errors. A couple of questions: * did this happen after you changed Valgrind version, or is this with a Valgrind that has been known (to you) to work OK for some time? * can you send the command line parameters you are using? J |
|
From: Yeshurun, M. <mei...@in...> - 2008-07-14 22:52:57
|
I'm using version 3.3.0, which has been working great. The command line parameters I used were --log-file=name --error-limit=no --num-callers=50 The crash I'm trying to debug is very illusive and nondeterministic. Thanks, Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Monday, July 14, 2008 1:08 PM To: val...@li... Cc: Yeshurun, Meir Subject: Re: [Valgrind-users] "glibc detected..." error > Recently, we've been seeing messages like "glibc detected: corrupted > double-linked list" followed by a crash. Memcheck reported absolutely no > errors. A couple of questions: * did this happen after you changed Valgrind version, or is this with a Valgrind that has been known (to you) to work OK for some time? * can you send the command line parameters you are using? 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: Julian S. <js...@ac...> - 2008-07-15 07:16:53
|
On Tuesday 15 July 2008 00:52, Yeshurun, Meir wrote: > I'm using version 3.3.0, which has been working great. > > The command line parameters I used were --log-file=name --error-limit=no > --num-callers=50 Try adding --freelist-vol=<huge_number>, say 100000000. Increase it until the machine runs out of memory. This causes memcheck to hold onto freed memory longer before recycling it, and _might_ catch some more use-after-free cases. In memcheck/mc_include.h, change MC_MALLOC_REDZONE_SZB from 16 to 64. This allows memcheck to detect block overruns of up to 64 bytes instead of up to 16 at the cost of running slower and using more memory. You can increase it arbitrarily further but above 128 you'll need to change some assertions elsewhere in the code. Make sure you don't use --partial-loads-ok=yes. This can hide bad writes sometimes. Make sure you fix all Memcheck complains prior to this point, particularly bad writes and reads. You might want to upgrade to 3.3.1. 3.3.0 contains an obscure regalloc bug, which although apparently very unlikely to be a problem, is something you can do without. > The crash I'm trying to debug is very illusive and nondeterministic. So is this a threading problem? Is the app threaded? J |
|
From: Yeshurun, M. <mei...@in...> - 2008-07-17 22:02:30
|
Thanks a lot for the advice. No, the application is not multithreaded, and there are absolutely no errors reported by Valgrind. I have a question regarding the free list volume and red zones you mentioned. I assume that Valgrind always knows, for each byte in the heap, whether the process is allowed to access it (i.e., it is inside a block that was allocated and not yet freed). So the free list volume and the red zone increase is just for enabling Valgrind to tell you where the block was freed, or the boundaries of which block were exceeded. But Valgrind is supposed to always notify you of an invalid read/write, regardless of the size of the free list and the red zones. Is that correct? Thanks, Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Tuesday, July 15, 2008 10:09 AM To: Yeshurun, Meir Cc: val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error On Tuesday 15 July 2008 00:52, Yeshurun, Meir wrote: > I'm using version 3.3.0, which has been working great. > > The command line parameters I used were --log-file=name --error-limit=no > --num-callers=50 Try adding --freelist-vol=<huge_number>, say 100000000. Increase it until the machine runs out of memory. This causes memcheck to hold onto freed memory longer before recycling it, and _might_ catch some more use-after-free cases. In memcheck/mc_include.h, change MC_MALLOC_REDZONE_SZB from 16 to 64. This allows memcheck to detect block overruns of up to 64 bytes instead of up to 16 at the cost of running slower and using more memory. You can increase it arbitrarily further but above 128 you'll need to change some assertions elsewhere in the code. Make sure you don't use --partial-loads-ok=yes. This can hide bad writes sometimes. Make sure you fix all Memcheck complains prior to this point, particularly bad writes and reads. You might want to upgrade to 3.3.1. 3.3.0 contains an obscure regalloc bug, which although apparently very unlikely to be a problem, is something you can do without. > The crash I'm trying to debug is very illusive and nondeterministic. So is this a threading problem? Is the app threaded? 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: Julian S. <js...@ac...> - 2008-07-18 18:54:47
|
On Friday 18 July 2008 00:01, Yeshurun, Meir wrote:
> I assume that Valgrind always knows, for each byte in the heap, whether
> the process is allowed to access it
yes. In fact for each byte in the entire process it knows that.
> But Valgrind is supposed to always notify you of an invalid read/write,
> regardless of the size of the free list and the red zones.
That's unfortunately not exactly correct (partially correct).
Consider the following two problems:
1. You allocate a block of size 1000 (say). By default the
16 byte area just beyond each end is marked as no-access.
That guarantees Memcheck can detect accesses in these areas.
But suppose it is an array of 20 50-byte items, and you have an
off-by-one error in the indexing. Then you get an access which
is 50 bytes outside the block. Will Memcheck detect that? Maybe,
maybe not. If this incorrect address happens to be inside a
neighbouring block, then no error will be reported.
In this example, increasing the red zone size to be 50 bytes or
more will guarantee that Memcheck detects the error.
2. You allocate a block of size N and then free it. A very long time
later you (incorrectly) access the block. Will Memcheck detect that?
Again, depends. Memcheck marks freed memory as no-access, to detect
this kind of error. But the problem is that if freed memory remains
no-access for ever, then the process will run out of memory in a simple
loop like this
while (1) { char* x = malloc(10); free(x); }
So eventually Memcheck makes memory from freed blocks available for
allocation again. When it does that, it can no longer detect invalid
accesses to these freed blocks.
This is what the --freelist-vol parameter is for. Higher settings
cause Memcheck to hold on to freed memory for longer, which increases
the probability of detecting reads/writes to freed memory, but it also
increases the total memory consumption of the process.
J
|
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 11:07:11
|
Hi,
I'd like to share with you the reason Valgrind could not reproduce the
memory violation we had. The faulty module was making decisions based on
block addresses, and the corruption only occurred when those addresses
satisfied certain conditions (it's actually a very well-written module
except for this bug).
I guess the simplest example of this would be the following program:
#include <stdlib.h>
#include <stdio.h>
int main()
{
void *p = malloc(8), *p2;
printf("%p\n", p);
scanf("%p", &p2);
if (p2 == p)
free((char*)p + 100);
}
If you enter the value printed, you get a glibc complaint. Now run
Valgrind, enter the same value as before, and Valgrind is silent. Same
binary, same input, but the problem is gone.
I believe this is the most common reason for cases where memory
corruptions are not reproduced when running Valgrind.
So is there any chance Valgrind could ever be enhanced to maintain
variable and heap block addresses so they match the addresses of a
native run?
Thanks!
Meir
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]
Sent: Friday, July 18, 2008 11:06 AM
To: val...@li...
Cc: Yeshurun, Meir
Subject: Re: [Valgrind-users] "glibc detected..." error
On Friday 18 July 2008 00:01, Yeshurun, Meir wrote:
> I assume that Valgrind always knows, for each byte in the heap,
whether
> the process is allowed to access it
yes. In fact for each byte in the entire process it knows that.
> But Valgrind is supposed to always notify you of an invalid
read/write,
> regardless of the size of the free list and the red zones.
That's unfortunately not exactly correct (partially correct).
Consider the following two problems:
1. You allocate a block of size 1000 (say). By default the
16 byte area just beyond each end is marked as no-access.
That guarantees Memcheck can detect accesses in these areas.
But suppose it is an array of 20 50-byte items, and you have an
off-by-one error in the indexing. Then you get an access which
is 50 bytes outside the block. Will Memcheck detect that? Maybe,
maybe not. If this incorrect address happens to be inside a
neighbouring block, then no error will be reported.
In this example, increasing the red zone size to be 50 bytes or
more will guarantee that Memcheck detects the error.
2. You allocate a block of size N and then free it. A very long time
later you (incorrectly) access the block. Will Memcheck detect that?
Again, depends. Memcheck marks freed memory as no-access, to detect
this kind of error. But the problem is that if freed memory remains
no-access for ever, then the process will run out of memory in a
simple
loop like this
while (1) { char* x = malloc(10); free(x); }
So eventually Memcheck makes memory from freed blocks available for
allocation again. When it does that, it can no longer detect invalid
accesses to these freed blocks.
This is what the --freelist-vol parameter is for. Higher settings
cause Memcheck to hold on to freed memory for longer, which increases
the probability of detecting reads/writes to freed memory, but it
also
increases the total memory consumption of the process.
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: Tom H. <to...@co...> - 2008-08-01 11:14:44
|
In message <D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> I guess the simplest example of this would be the following program:
>
> #include <stdlib.h>
> #include <stdio.h>
> int main()
> {
> void *p = malloc(8), *p2;
> printf("%p\n", p);
> scanf("%p", &p2);
> if (p2 == p)
> free((char*)p + 100);
> }
>
> If you enter the value printed, you get a glibc complaint. Now run
> Valgrind, enter the same value as before, and Valgrind is silent. Same
> binary, same input, but the problem is gone.
If you enter the value from the non-valgrind run, yes. If you enter
the value from the valgrind run then it complains.
> I believe this is the most common reason for cases where memory
> corruptions are not reproduced when running Valgrind.
I don't. I imagine that it's an incredibly rare case as it requires
that an address is somehow propagated from a non-valgrind run to a
valgrind run with an expectation that the address will mean something.
> So is there any chance Valgrind could ever be enhanced to maintain
> variable and heap block addresses so they match the addresses of a
> native run?
No chance whatsoever.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2008-08-01 11:27:29
|
> I'd like to share with you the reason Valgrind could not reproduce the > memory violation we had. Hi! Thanks for the feedback. It's useful to know where Memcheck is not doing as well as it could. However, there's something very strange about this. In your test case, Memcheck should report an invalid free, and for me, using valgrind 3.3.1, it does, both for a 32-bit and 64-bit executable: $ gcc -g -O -o badfree-32 badfree.c -m32 $ gcc -g -O -o badfree-64 badfree.c -m64 $ v33BRANCH -q ./badfree-32 0x6fe2028 0x6fe2028 ==25574== Invalid free() / delete / delete[] ==25574== at 0x47EA42C: free (vg_replace_malloc.c:323) ==25574== by 0x80484AA: main (badfree.c:9) ==25574== Address 0x6fe208c is not stack'd, malloc'd or (recently) free'd $ v33BRANCH -q ./badfree-64 0x516a030 0x516a030 ==25580== Invalid free() / delete / delete[] ==25580== at 0x4C2295E: free (vg_replace_malloc.c:323) ==25580== by 0x40062F: main (badfree.c:9) ==25580== Address 0x516a094 is not stack'd, malloc'd or (recently) free'd Can you send the result of running your test executable with -v, so I can see that Valgrind is intercepting both malloc and free? What compiler did you try the test case with? If icc, does it make any difference if you use gcc? > So is there any chance Valgrind could ever be enhanced to maintain > variable and heap block addresses so they match the addresses of a > native run? Well, I suspect this is not the root cause of the problem you are seeing. J |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 11:41:20
|
Hi, You were supposed to enter 0x6fe2028 when running Valgrind as well (same input in both runs). Anyway, forget about my silly example program. The point I was trying to make is that it's perfectly legal (and not uncommon) for C/C++ programs to make decisions based on comparisons (<>) of pointer values. Valgrind changes pointer values, and that can cause program behavior to change, and as a result, memory violations can disappear. I'm pretty sure that when you run the same binary on the same inputs you get the same pointer values because the linker/loader and the libc allocator are deterministic Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Friday, August 01, 2008 2:19 PM To: Yeshurun, Meir Cc: val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error > I'd like to share with you the reason Valgrind could not reproduce the > memory violation we had. Hi! Thanks for the feedback. It's useful to know where Memcheck is not doing as well as it could. However, there's something very strange about this. In your test case, Memcheck should report an invalid free, and for me, using valgrind 3.3.1, it does, both for a 32-bit and 64-bit executable: $ gcc -g -O -o badfree-32 badfree.c -m32 $ gcc -g -O -o badfree-64 badfree.c -m64 $ v33BRANCH -q ./badfree-32 0x6fe2028 0x6fe2028 ==25574== Invalid free() / delete / delete[] ==25574== at 0x47EA42C: free (vg_replace_malloc.c:323) ==25574== by 0x80484AA: main (badfree.c:9) ==25574== Address 0x6fe208c is not stack'd, malloc'd or (recently) free'd $ v33BRANCH -q ./badfree-64 0x516a030 0x516a030 ==25580== Invalid free() / delete / delete[] ==25580== at 0x4C2295E: free (vg_replace_malloc.c:323) ==25580== by 0x40062F: main (badfree.c:9) ==25580== Address 0x516a094 is not stack'd, malloc'd or (recently) free'd Can you send the result of running your test executable with -v, so I can see that Valgrind is intercepting both malloc and free? What compiler did you try the test case with? If icc, does it make any difference if you use gcc? > So is there any chance Valgrind could ever be enhanced to maintain > variable and heap block addresses so they match the addresses of a > native run? Well, I suspect this is not the root cause of the problem you are seeing. 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: Paul W. <pa...@bl...> - 2008-08-04 13:38:44
|
On Fri, Aug 01, 2008 at 02:40:55PM +0300, Yeshurun, Meir wrote: > I'm pretty sure that when you run the same binary on the same inputs you > get the same pointer values because the linker/loader and the libc > allocator are deterministic No, not reliably. Security and optimisation techniques such as address space randomization and prelinking will break that assumption. Any programme which is treating unrelated addresses as more than opaque cookies is likely to be broken, I would think. (I'm including "use them for tree node sorting" in the opaque cookies use, for what it's worth.) -- Paul Java/XML are the hammer and the Internet is the thumb. -- rone |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-04 13:52:18
|
> No, not reliably. As I said before, Valgrind's effect on pointer values is much larger than the native randomization, so a very frequent memory corruption can become completely non-reproducible under Valgrind. > (I'm including "use them for tree node sorting" in the opaque cookies use, > for what it's worth.) As I said before - what if the bug is in your binary tree (for example)? The bug I had was indeed inside a very low level data structure. Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Paul Walker Sent: Monday, August 04, 2008 4:39 PM To: val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error On Fri, Aug 01, 2008 at 02:40:55PM +0300, Yeshurun, Meir wrote: > I'm pretty sure that when you run the same binary on the same inputs you > get the same pointer values because the linker/loader and the libc > allocator are deterministic No, not reliably. Security and optimisation techniques such as address space randomization and prelinking will break that assumption. Any programme which is treating unrelated addresses as more than opaque cookies is likely to be broken, I would think. (I'm including "use them for tree node sorting" in the opaque cookies use, for what it's worth.) -- Paul Java/XML are the hammer and the Internet is the thumb. -- rone ------------------------------------------------------------------------ - 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: Paul W. <pa...@bl...> - 2008-08-04 14:07:47
|
On Mon, Aug 04, 2008 at 04:52:16PM +0300, Yeshurun, Meir wrote: > As I said before - what if the bug is in your binary tree (for example)? > The bug I had was indeed inside a very low level data structure. If it needs a particular pattern of cookies in order to create the bad situation, then sure, the behaviour's likely to change inside valgrind compared to out. This is no different to the fact the behaviour would change from machine to machine, depending on OS version, memory loading, installed packages, and so on. As far as I can see this is one of those situations where valgrind doesn't help much, but doesn't really make things any worse either. -- Paul |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-04 15:20:26
|
It's interesting how everybody finds this so obvious now. Nobody told me anything about this possibility when I described my problem here before finding the bug. I hope other readers of the list found this educational, and a few words about this issue in the Valgrind user's manual might be very nice. The important point to remember is that besides un-initialized variables, there is another source of non-determinism in a single-threaded program (pointer values), and not only is Valgrind unable to help with that, it actually magnifies this form of non-determinism. This should be clear to every Valgrind user. Cheers, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Paul Walker Sent: Monday, August 04, 2008 5:08 PM To: val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error On Mon, Aug 04, 2008 at 04:52:16PM +0300, Yeshurun, Meir wrote: > As I said before - what if the bug is in your binary tree (for example)? > The bug I had was indeed inside a very low level data structure. If it needs a particular pattern of cookies in order to create the bad situation, then sure, the behaviour's likely to change inside valgrind compared to out. This is no different to the fact the behaviour would change from machine to machine, depending on OS version, memory loading, installed packages, and so on. As far as I can see this is one of those situations where valgrind doesn't help much, but doesn't really make things any worse either. -- Paul ------------------------------------------------------------------------ - 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: Ashley P. <api...@co...> - 2008-08-01 11:18:32
|
On Fri, 2008-08-01 at 14:07 +0300, Yeshurun, Meir wrote: > Hi, > > I'd like to share with you the reason Valgrind could not reproduce the > memory violation we had. The faulty module was making decisions based > on > block addresses, and the corruption only occurred when those addresses > satisfied certain conditions (it's actually a very well-written module > except for this bug). > I believe this is the most common reason for cases where memory > corruptions are not reproduced when running Valgrind. It's only the second time I've ever heard of such a bug, the previous time was when porting code to ia64 and the code was doing a < on a stack and heap address, on ia64 these two are in the other order to i386. It's a fairly rare bug. > So is there any chance Valgrind could ever be enhanced to maintain > variable and heap block addresses so they match the addresses of a > native run? You'll find the native addresses you get vary not only from system to system but also from run to run on the same system, what you ask for is would not only be highly difficult I'm not sure it would be of value. What might be interesting is knowing which memory locations contained pointers and reporting errors if they are ever used in comparisons, I suspect there are legitimate reasons for doing this that i haven't thought of however so I'd expect the false-positive rate would be quite high. Ashley Pittman. |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 11:29:22
|
> What might be interesting is knowing which memory locations contained > pointers and reporting errors if they are ever used in comparisons, I > suspect there are legitimate reasons for doing this that i haven't > thought of however so I'd expect the false-positive rate would be quite > high. Enabling this using an optional flag might be s good solution. BTW, don't take my example program to literally. The faulty module was doing < > pointer comparisons, which is quite common in C/C++. It wasn't looking for a specific memory address using ==/!=. --------------------------------------------------------------------- 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: Julian S. <js...@ac...> - 2008-08-01 11:37:46
|
> Enabling this using an optional flag might be s good solution. BTW, > don't take my example program to literally. The faulty module was doing > < > > pointer comparisons, which is quite common in C/C++. It wasn't looking > for a specific memory address using ==/!=. Any program which makes any assumptions at all about the relative values from different calls to malloc, new, etc, is broken. The only safe thing to do is assume that malloc is a black box which gives out completely arbitrary addresses. And that it produces a different sequence of addresses on different runs of the same program with the same input data. J |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 11:42:51
|
Does the following code mean a program is broken? if (p1 < p2) ... else ... -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Friday, August 01, 2008 2:26 PM To: Yeshurun, Meir Cc: Ashley Pittman; val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error > Enabling this using an optional flag might be s good solution. BTW, > don't take my example program to literally. The faulty module was doing > < > > pointer comparisons, which is quite common in C/C++. It wasn't looking > for a specific memory address using ==/!=. Any program which makes any assumptions at all about the relative values from different calls to malloc, new, etc, is broken. The only safe thing to do is assume that malloc is a black box which gives out completely arbitrary addresses. And that it produces a different sequence of addresses on different runs of the same program with the same input data. 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: Tom H. <to...@co...> - 2008-08-01 11:46:07
|
In message <D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> Does the following code mean a program is broken?
>
> if (p1 < p2)
> ...
> else
> ...
If the two pointers do not point to members of the same array then
yes, according to the C standard the result is not defined.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 11:56:45
|
If so, Memcheck should be able to report it.
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Friday, August 01, 2008 2:46 PM
To: val...@li...
Subject: Re: [Valgrind-users] "glibc detected..." error
In message
<D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> Does the following code mean a program is broken?
>
> if (p1 < p2)
> ...
> else
> ...
If the two pointers do not point to members of the same array then
yes, according to the C standard the result is not defined.
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: Tom H. <to...@co...> - 2008-08-01 12:14:34
|
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/
|
|
From: Ashley P. <api...@co...> - 2008-08-01 11:50:04
|
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 ==. On Fri, 2008-08-01 at 14:40 +0300, Yeshurun, Meir wrote: > I'm pretty sure that when you run the same binary on the same inputs you > get the same pointer values because the linker/loader and the libc > allocator are deterministic The linker is *not* deterministic and neither is the libc allocator although for different reasons. perlink and address space randomization are two other sources of entropy here, your assertion about addresses being constant between different runs of the same program is false. Ashley Pittman. |
|
From: Julian S. <js...@ac...> - 2008-08-01 12:01:05
|
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. But that's not quite the same as what I was trying to say. What I mean is, if the program depends on some (really, on _any)) assumption about the sequence of addresses produced by malloc, eg char* p1 = malloc(10); char* p2 = malloc(10); assert(p1 < p2); // duh then it's broken. J |
|
From: Yeshurun, M. <mei...@in...> - 2008-08-01 12:06:21
|
So what you're saying is even Valgrind's code itself contains the pointer comparisons I'm talking about. If the pointer values change, the behavior of the program will change, and a memory violation will not be reproduced. Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Friday, August 01, 2008 2:52 PM To: Yeshurun, Meir Cc: Ashley Pittman; val...@li... Subject: Re: [Valgrind-users] "glibc detected..." error 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. But that's not quite the same as what I was trying to say. What I mean is, if the program depends on some (really, on _any)) assumption about the sequence of addresses produced by malloc, eg char* p1 = malloc(10); char* p2 = malloc(10); assert(p1 < p2); // duh then it's broken. 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. |