|
From: Mayukh B. <ma...@gm...> - 2006-03-03 18:11:21
|
Hi, I am a IBM Purify user looking to start serious valgrind memchecking. One of the requirements for migrating is that my program "foo" absolutely needs to know that it is being run by valgrind. Using that knowledge, it will not do certain things. Purify would give me that information through a variable and foo would know easily that "purify_is_running" or not. What could be possible ways of getting the same effect in valgrind? Is there an environment variable that valgrind would set that foo can look for? Thanks, -Mayukh. |
|
From: Michael S. <ms...@xi...> - 2006-03-03 18:16:57
|
On 3/3/06, Mayukh Bhattacharya <ma...@gm...> wrote:
>
> Hi,
>
> I am a IBM Purify user looking to start serious valgrind memchecking.
>
> One of the requirements for migrating is that my program "foo" absolutely
> needs to know that it is being run by valgrind. Using that knowledge,
> it will not do certain things. Purify would give me that information
> through a variable and foo would know easily that "purify_is_running"
> or not.
You can #include <valgrind/valgrind.h>, then use the
RUNNING_ON_VALGRIND macro, like:
if (RUNNING_ON_VALGRIND) {
do_special_thing();
}
else {
do_normal_thing();
}
You need the header file for this, but the application will run
normally without valgrind; it adds no runtime dependencies.
Mike
|
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 19:01:40
|
Michael Smith <msmith <at> xiph.org> writes: > You can #include <valgrind/valgrind.h>, then use the > RUNNING_ON_VALGRIND macro, like: > > if (RUNNING_ON_VALGRIND) { > do_special_thing(); > } > else { > do_normal_thing(); > } Thank you! I verified that this works. -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 18:24:45
|
> One of the requirements for migrating is that my program "foo" absolutely > needs to know that it is being run by valgrind. Why is that? Timing issues, or something else? J |
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 18:53:49
|
Julian Seward <jseward <at> acm.org> writes: > > > > One of the requirements for migrating is that my program "foo" absolutely > > needs to know that it is being run by valgrind. > > Why is that? Timing issues, or something else? > > J > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > We have a portion of our code where we try to figure out the cache-size, cpuspeed, etc., of the machine it is running on. For learning about the cache-size and miss-ratio etc, we generate larger and larger vectors. This process usually takes about a second of cpu. This part of our code is simply for precise benchmarking and QA'ing of our code. Otherwise it is useless. For some reason, valgrind (first with the cachegrind tool) didn't like this part of our code and simply choked. We got around by disabling that part of the code. Later, we tried running memcheck and again it had the same problem with this piece of code. I could try to reproduce this in a smaller C program, if you are interested. It might take me a couple of days to get to it, though. -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 18:59:49
|
> For some reason, valgrind (first with the cachegrind tool) didn't like this > part of our code and simply choked. Choked in what sense? Died and spewed out a load of messages in the process? If so, just send them (and tell us what version of V you are using.) J |
|
From: Mayukh B. <ma...@gm...> - 2006-03-03 19:08:55
|
Julian Seward <jseward <at> acm.org> writes: > > > > For some reason, valgrind (first with the cachegrind tool) didn't like this > > part of our code and simply choked. > > Choked in what sense? Died and spewed out a load of messages in the > process? If so, just send them (and tell us what version of V you > are using.) > > J > > It got stuck for a very long time (several hours vs. 2 seconds without valgrind) before I killed it. Version: ==15561== Using valgrind-2.2.0, a program supervision framework for x86-linux. I will try to reproduce the problem and send it over the weekend. Thank you, -Mayukh. |
|
From: Julian S. <js...@ac...> - 2006-03-03 19:14:43
|
> ==15561== Using valgrind-2.2.0, a program supervision framework for > x86-linux. Whoa! That's ancient. I suggest you upgrade to 3.1.0 and try again. J |
|
From: Mayukh B. <ma...@gm...> - 2006-03-10 06:17:41
|
Julian Seward <jseward <at> acm.org> writes: > > > Whoa! That's ancient. I suggest you upgrade to 3.1.0 and try again. > > J > You were right. 3.1.0 does not have this problem. Thank you, -Mayukh. |