|
From: Lucas B. <bra...@re...> - 2004-08-03 16:14:18
|
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. -- []'s Lucas Brasilino bra...@re... http://www.recife.pe.gov.br Emprel - Empresa Municipal de Informatica (pt_BR) Municipal Computing Enterprise (en_US) Recife - Pernambuco - Brasil Fone: +55-81-34167078 |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 18:17:01
|
On Tue, 3 Aug 2004, Lucas Brasilino wrote: > 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 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? > 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 |
|
From: Lucas B. <bra...@re...> - 2004-08-04 11:26:03
|
Hi Nicholas: >> 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 > > > 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). >> 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 -- []'s Lucas Brasilino bra...@re... http://www.recife.pe.gov.br Emprel - Empresa Municipal de Informatica (pt_BR) Municipal Computing Enterprise (en_US) Recife - Pernambuco - Brasil Fone: +55-81-34167078 |
|
From: Nicholas N. <nj...@ca...> - 2004-08-04 14:35:46
|
On Wed, 4 Aug 2004, Lucas Brasilino wrote: >> 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. > 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. >> 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 |
|
From: Lucas B. <bra...@re...> - 2004-08-04 15:47:03
|
Hi Nicholas: >> 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 -- []'s Lucas Brasilino bra...@re... http://www.recife.pe.gov.br Emprel - Empresa Municipal de Informatica (pt_BR) Municipal Computing Enterprise (en_US) Recife - Pernambuco - Brasil Fone: +55-81-34167078 |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 09:41:36
|
On Wed, 4 Aug 2004, Lucas Brasilino wrote: > 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 |