[Valgrind-users] valgrind ending with "Warning: set address range perms: large range..."

[Lucas Brasilino]

Hi!

I'm trying to debug some memory leaks using valgrind 2.0.0
and options "-v --leak-check=yes" but it is ending with:

==<PID>== Warning: set address range perms: large range 538090744, a 0, v 0


And kernel VM (2.4.20-31.9) ends valgrind with "out of memory".
When I run the application without valgrind, it works just fine.
Anybody knows something about is annoying issue?

thanks a lot in advance.

[Nicholas Nethercote]

Post by Lucas Brasilino
I'm trying to debug some memory leaks using valgrind 2.0.0
==<PID>== Warning: set address range perms: large range 538090744, a 0, v 0

That happens when Valgrind sees a big allocation or deallocation via
malloc(), free, brk(), mmap(), munmap(), etc. It's not necessarily a
problem, but it is a bit suspicious -- is your program likely to be
allocating or deallocating 530+ MB in one hit, either directly or via a
library?

Post by Lucas Brasilino
And kernel VM (2.4.20-31.9) ends valgrind with "out of memory".
When I run the application without valgrind, it works just fine.
Anybody knows something about is annoying issue?

You could try using --tool=addrcheck, which uses less memory than
--tool=memcheck (but also does less thorough checking) You could also try
valgrind 2.1.2, to see if that acts any different.

N

[Lucas Brasilino]

Post by Nicholas Nethercote

Post by Lucas Brasilino
I'm trying to debug some memory leaks using valgrind 2.0.0
==<PID>== Warning: set address range perms: large range 538090744, a 0, v 0

That happens when Valgrind sees a big allocation or deallocation via
malloc(), free, brk(), mmap(), munmap(), etc. It's not necessarily a
problem, but it is a bit suspicious -- is your program likely to be
allocating or deallocating 530+ MB in one hit, either directly or via a
library?

No, it is not allocating that big. When I run my application
without valgrind, every thing works fine, ie, VM not kills it.
May be a library I'm using... I gonna check it out. I'm using
libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and
libpthread).

Post by Nicholas Nethercote

Post by Lucas Brasilino
And kernel VM (2.4.20-31.9) ends valgrind with "out of memory".
When I run the application without valgrind, it works just fine.
Anybody knows something about is annoying issue?

You could try using --tool=addrcheck, which uses less memory than
--tool=memcheck (but also does less thorough checking) You could also
try valgrind 2.1.2, to see if that acts any different.

I've tried with --tool=memcheck and I've got the same
results, so I downgrade back to 2.0.0.


thanks a lot for you answer.
bests regards

[Nicholas Nethercote]

Post by Lucas Brasilino

Post by Nicholas Nethercote
That happens when Valgrind sees a big allocation or deallocation via
malloc(), free, brk(), mmap(), munmap(), etc. It's not necessarily a
problem, but it is a bit suspicious -- is your program likely to be
allocating or deallocating 530+ MB in one hit, either directly or via a
library?

No, it is not allocating that big. When I run my application
without valgrind, every thing works fine, ie, VM not kills it.

Well, Memcheck more than doubles memory usage, so not running out of
memory normally doesn't indicate much.

Post by Lucas Brasilino
May be a library I'm using... I gonna check it out. I'm using
libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and
libpthread).

It's potentially a valgrind bug. It would be great if you could isolate a
test case and send us it.

Post by Lucas Brasilino

Post by Nicholas Nethercote
You could try using --tool=addrcheck, which uses less memory than
--tool=memcheck (but also does less thorough checking) You could also try
valgrind 2.1.2, to see if that acts any different.

I've tried with --tool=memcheck and I've got the same
results, so I downgrade back to 2.0.0.

Did --tool=addrcheck help?

N

[Lucas Brasilino]

Post by Nicholas Nethercote

Post by Lucas Brasilino
May be a library I'm using... I gonna check it out. I'm using
libxml2 2.6.6, gdbm 1.8.0 and libpam 0.7.5 (among glibc, libz and
libpthread).

It's potentially a valgrind bug. It would be great if you could isolate
a test case and send us it.

At first view, I thought it was a valgrind bug. But
going deeper in my code, the problem was a variable that was
declared without value, which is used to allocate its number
of an given structure. So, it was my mistake. Thanks a lot
for you time and patience :)

bests regards

[Nicholas Nethercote]

Post by Lucas Brasilino
At first view, I thought it was a valgrind bug. But
going deeper in my code, the problem was a variable that was
declared without value, which is used to allocate its number
of an given structure. So, it was my mistake. Thanks a lot
for you time and patience :)

Good! I'm glad you've solved your problem.

But it's identified a chink in Memcheck's checking -- if you pass an
uninitialised value to malloc(), no warning is given.

The problem is that Memcheck implements malloc() via a "client request".
The details of client requests aren't important here, other than the
validity of arguments to client requests is not checked. Similar to how
arguments to system calls are not checked. (Memory pointed to by system
call args is checked, but not the args themselves.) This means that a lot
of the args to pthread functions are also not checked, because they are
also mostly implemented using client requests.

I think it shouldn't be too hard to fix this situation. I'll take a look.

N