[Valgrind-developers] About the message of "Warning: set address range perms: large range <number>"

[zhangyan]

I have used the valgrind for a long time,and recently I am writing a program
which will allocate a very large block of memory once a time,and The
valgrind will always report the warning "set address range perms: large
range <number>".

That's is really annoying.



The version of valgrind which I use is 3.3.0,and I have read the source code
of memcheck/mc_main.c this file,

that indicate if we allocate a memory more than 100MB once a time,the
valgrind will report this warning. So I want to know there is any reason why
100MB exactly???



And I guess the reason why set a threshold is that if I allocate too much
bytes as a block a time,the valgrind can't trace it exactly,even this block
of memory will be "definitely lost",the valgrind will report "possibly
lost".Is it correct???



I made this guess becauase recently I have done a experiement to test
valgrind's exactness,I allocate a specific number of bytes once a time,and
the program is like this

#define N 79814486

void foo()

{

char *a=(char*)malloc(N);

}

int main()

{

foo();

return 0;

}

And I thought the valgrind will report the error message of "definitely
lost",but when the N is more than or equal to 79814486,the valgrind will
report the error message of "possbily lost" instead of "definitely lost".

So I guess the reason why the developer set the 100MB is because if we
allocate too big

[Nicholas Nethercote]

Post by zhangyan
I have used the valgrind for a long time,and recently I am writing a program
which will allocate a very large block of memory once a time,and The
valgrind will always report the warning "set address range perms: large
range <number>".
That's is really annoying.
The version of valgrind which I use is 3.3.0,and I have read the source code
of memcheck/mc_main.c this file,
that indicate if we allocate a memory more than 100MB once a time,the
valgrind will report this warning. So I want to know there is any reason why
100MB exactly???

The number 100MB isn't particularly significant. The warning is there to
help debug Valrind itself -- at various times the memory size number has
been incorrect, and flagging large allocations catches many of these cases.
So feel free to comment out the relevant line and recompile.

Post by zhangyan
And I guess the reason why set a threshold is that if I allocate too much
bytes as a block a time,the valgrind can't trace it exactly,even this block
of memory will be "definitely lost",the valgrind will report "possibly
lost".Is it correct???
I made this guess becauase recently I have done a experiement to test
valgrind's exactness,I allocate a specific number of bytes once a time,and
the program is like this
#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}
And I thought the valgrind will report the error message of "definitely
lost",but when the N is more than or equal to 79814486,the valgrind will
report the error message of "possbily lost" instead of "definitely lost".
So I guess the reason why the developer set the 100MB is because if we
allocate too big

No, the two things are unrelated. Whether you get "definitely" or
"possibly" lost is largely a matter of luck -- if there are any values that
could conceivably point into the middle of a block, it's considered
"possibly" lost. (See the manual for more explanation.) As you make blocks
bigger, this becomes more likely.

Nick

[zhangyan]

Post by Nicholas Nethercote
No, the two things are unrelated. Whether you get "definitely" or

"possibly" > lost is largely a matter of luck -- if there are any values
that could conceivably > point into the middle of a block, it's considered
"possibly" lost. (See the 〉> manual for more explanation.) As you make
blocks bigger, this becomes more > likely.


Well,3ks you for explanation of report the warning of "set address range
perms",it's impressed.But to the second question,as you watch this source
file

#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}

The memory allocated by (char*)malloc(N) is definitely lost,but why the
valgrind give me the "possibly lost".And do you think is there any possible
value points into the middle of the allocated block ??? if it's,what is the
value which points to the allocated block possibly???

I really appreciate your explanation of the warning as a developer,because
our company come across many warnings of this kind,and we are really worried
about that whether these warnings indicating our programs have a bunch of
bugs:-)

[Nicholas Nethercote]

Post by zhangyan
#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}
The memory allocated by (char*)malloc(N) is definitely lost,but why the
valgrind give me the "possibly lost".And do you think is there any possible
value points into the middle of the allocated block ??? if it's,what is the
value which points to the allocated block possibly???

You need to understand what Valgrind means by "possibly" lost. Read the
manual:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks

There could be random values in the address space that look like pointers
into a block, but which aren't really. The bigger a block is, the more
likely this is to happen.

Nick

[zhangyan]

Thank you for a lot,I think I figure out this problem quiet clearly.
Really appreciate your reply:-)

--------------------------------------------------------------------

Post by zhangyan
#define N 79814486
void foo()
{
char *a=(char*)malloc(N);
}
int main()
{
foo();
return 0;
}
The memory allocated by (char*)malloc(N) is definitely lost,but why the
valgrind give me the "possibly lost".And do you think is there any possible
value points into the middle of the allocated block ??? if it's,what is the
value which points to the allocated block possibly???

You need to understand what Valgrind means by "possibly" lost. Read the
manual:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks

There could be random values in the address space that look like pointers
into a block, but which aren't really. The bigger a block is, the more
likely this is to happen.

Nick