|
From: Philippe W. <phi...@sk...> - 2012-11-05 21:39:31
|
On Mon, 2012-11-05 at 14:24 +0100, Igmar Palsenberg wrote: > >> I can enable malloc debugging, but that gives me way to much output. > > > > I don't get it - if you know where it leaks you can fix it, no? If you want to > > get memory adresses of leaked blocks (for whatever reason?), just use > > memcheck's --leak-check=full, afaik that shows the addresses and size of the > > leaked objects. --leak-check=full does not give the memory addresses of the leaked blocks, it just prints the stack traces (+ nr + sum of sizes) where the leaked blocks have been allocated > > Since parser_native() has about 300 code paths, I need to know what the content of the blocks is, so I can free the objects in the proper place. > > I hope this makes things clear. I couldn't find the answer to my question in the manpage, of valgrind docs. If not yet done, upgrade to the last version of Valgrind (3.8.1). Then use gdb+vgdb to connect to your application. For this, give --vgdb-error=0 and follow the on-screen instructions. Then place breakpoints at the relevant place(s) to do a leak search (e.g. just before the exit of main). When breakpoint reached, do a leak search from gdb, using : (gdb) monitor leak_search Note: there are some optional args to leak_search. use (gdb) monitor help and/or read manual for more info http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands Then use the following monitor command to find the list of leaked blocks (gdb) monitor block_list <a_loss_record_nr_output_by_leak_search> This will give the list of address and length for the leaked blocks of this loss record nr. You can then print the content using the normal gdb commands (you might have to cast the address to the type you want) Philippe |