|
From: Anders T. <to...@lu...> - 2005-04-18 10:44:42
|
I get these errors: ==30550== 173 (96 direct, 77 indirect) bytes in 2 blocks are definitely lost in loss record 44 of 135 ==30550== at 0x1B90659D: malloc (vg_replace_malloc.c:130) ==30550== by 0x80D4CB8: yyparse (grammar.y:106) ==30550== by 0x80D3C95: parsefile (parser.c:153) ==30550== by 0x80C11B6: main (mod.c:322) etc... is it possible to get a log with the actual pointer values involved? It would help me a great deal in my current situation, since there are lots of stuff allocated on the given line which is *not* lost, and some of it is lost. By knowing which pointers that are lost, it would be much easier for me to find the error. /Anders Torger |
|
From: Patrick O. <Pat...@in...> - 2005-04-18 11:03:16
|
On Mon, 2005-04-18 at 12:44 +0200, Anders Torger wrote: > I get these errors: > > ==30550== 173 (96 direct, 77 indirect) bytes in 2 blocks are definitely > lost in loss record 44 of 135 > ==30550== at 0x1B90659D: malloc (vg_replace_malloc.c:130) > ==30550== by 0x80D4CB8: yyparse (grammar.y:106) > ==30550== by 0x80D3C95: parsefile (parser.c:153) > ==30550== by 0x80C11B6: main (mod.c:322) > > etc... > > is it possible to get a log with the actual pointer values involved? I had asked the same question a while ago (see: http://thread.gmane.org/gmane.comp.debugging.valgrind/1741) The conclusion at that time was that it is not possible (and I think this is still true) and that adding it would be a kludge of little general use and thus not acceptable. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Paul P. <ppl...@gm...> - 2005-04-18 14:50:09
|
On 4/18/05, Anders Torger <to...@lu...> wrote: >=20 > is it possible to get a log with the actual pointer values involved? It > would help me a great deal in my current situation, since there are > lots of stuff allocated on the given line which is *not* lost, and some > of it is lost. By knowing which pointers that are lost, it would be > much easier for me to find the error. You could try Insure++, which (in theory) detects leaks "as they happen". This would allow you to stop in the debugger right where the problem is, rather then using conditional breakpoints (which are extremely slow if the code in question is hit often). Cheers, |