|
From: Igmar P. <mai...@pa...> - 2012-11-05 10:08:38
|
Hi, I've written a parser which a pretty large resulting codebase. I've still got a few memory leaks. The good part : I know where it leaks. The bad part : That line is a loop, where it allocates a struct, and parses that on into the parser itself. Debugging is an option, but extremely time consuming. What I really want is that valgrind can tell me what is the start of the leaked block. I can enable malloc debugging, but that gives me way to much output. Any suggestions ? Regards, Igmar |
|
From: Milian W. <ma...@mi...> - 2012-11-05 11:52:55
Attachments:
signature.asc
|
On Monday 05 November 2012 10:48:32 Igmar Palsenberg wrote: > Hi, > > I've written a parser which a pretty large resulting codebase. I've still > got a few memory leaks. The good part : I know where it leaks. > The bad part : That line is a loop, where it allocates a struct, and parses > that on into the parser itself. Debugging is an option, but extremely time > consuming. What I really want is that valgrind can tell me what is the > start of the leaked block. > > 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. bye -- Milian Wolff ma...@mi... http://milianw.de |
|
From: Igmar P. <mai...@pa...> - 2012-11-05 13:25:02
|
>> Hi,
>>
>> I've written a parser which a pretty large resulting codebase. I've still
>> got a few memory leaks. The good part : I know where it leaks.
>> The bad part : That line is a loop, where it allocates a struct, and parses
>> that on into the parser itself. Debugging is an option, but extremely time
>> consuming. What I really want is that valgrind can tell me what is the
>> start of the leaked block.
>>
>> 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.
>
The loop is roughly this :
while (!parser->terminate) {
input->token = scanner_token_construct(); /* The actual call to malloc is here */
scan(&input->state, input->token);
switch (input->token->opcode) {
case SCANNER_RETCODE_EOF:
/* FIXME : This doesn't work : In case the parser doesn't expect
* this, things will blow up. Properly handle EOF situations
*/
parser_native(input->parser, 0, input->token, parser);
break;
default:
parser_native(input->parser, input->token->opcode,
input->token, parser);
break;
}
input->state.limit = input->state.cursor;
if (input->token->opcode == SCANNER_RETCODE_EOF)
break;
}
valgrind gives me :
==19316== 67 (60 direct, 7 indirect) bytes in 3 blocks are definitely lost in loss record 2 of 2
==19316== at 0x4007EFC: malloc (vg_replace_malloc.c:270)
==19316== by 0x8064DED: scanner_token_construct (parser_native.c:55)
==19316== by 0x80656FE: is_parser_native_parse_input (parser_native.c:355)
==19316== by 0x8065518: is_parser_native_parse_file (parser_native.c:278)
==19316== by 0x8049749: test1 (test-native-parser.c:26)
==19316== by 0x4022739: run_single_test (TestRun.c:818)
==19316== by 0x402250A: run_single_suite (TestRun.c:759)
==19316== by 0x4021C44: CU_run_all_tests (TestRun.c:379)
==19316== by 0x4023FD4: basic_run_all_tests (Basic.c:228)
==19316== by 0x4023D32: CU_basic_run_tests (Basic.c:90)
==19316== by 0x804A09E: main (test-native-parser.c:199)
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.
Regards,
Igmar
|
|
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 |