|
From: Bob R. <bo...@br...> - 2005-08-13 13:12:15
|
Hi all, Just want to make sure I'm not loosing my mind. I'm using valgrind $ valgrind --version valgrind-2.4.0 on debian with $ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) When I run memcheck, I get the below output. I think they are malloc bugs because I can not reproduce them. Should this get reported to someone? or is should I assumme everything is OK? Thanks, Bob Rossi ==19807== Memcheck, a memory error detector for x86-linux. ==19807== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==19807== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==19807== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==19807== For more details, rerun with: -v ==19807== ==19807== ==19807== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1) ==19807== malloc/free: in use at exit: 256893 bytes in 2880 blocks. ==19807== malloc/free: 6011 allocs, 3131 frees, 1047585 bytes allocated. ==19807== For counts of detected errors, rerun with: -v ==19807== searching for pointers to 2880 not-freed blocks. ==19807== checked 418408 bytes. ==19807== ==19807== 74 bytes in 1 blocks are definitely lost in loss record 18 of 57 ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==19807== by 0x80514E0: load_file (sources.c:277) ==19807== by 0x80529A8: source_set_exec_line (sources.c:786) ==19807== by 0x804EC31: if_show_file (interface.c:1286) ==19807== by 0x804AA55: process_commands (cgdb.c:430) ==19807== by 0x804AC37: gdb_input (cgdb.c:539) ==19807== by 0x804B403: main_loop (cgdb.c:774) ==19807== by 0x804BA84: main (cgdb.c:967) ==19807== ==19807== ==19807== 413 bytes in 52 blocks are definitely lost in loss record 30 of 57 ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==19807== by 0x1BA23A5F: strdup (in /lib/libc-2.3.2.so) ==19807== by 0x80635CB: xstrdup (sys_util.c:44) ==19807== by 0x8063959: invoke_debugger (fork_util.c:178) ==19807== by 0x80574EC: a2_create_context (a2-tgdb.c:208) ==19807== by 0x80569C3: tgdb_client_create_context (tgdb_client_interface.c:291) ==19807== by 0x80550FA: tgdb_initialize (tgdb.c:383) ==19807== by 0x804A6E9: start_gdb (cgdb.c:320) ==19807== by 0x804B6DB: main (cgdb.c:879) ==19807== ==19807== ==19807== 14205 (1269 direct, 12936 indirect) bytes in 130 blocks are definitely lost in loss record 33 of 57 ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==19807== by 0x806355E: xmalloc (sys_util.c:28) ==19807== by 0x8061936: ibuf_init (ibuf.c:16) ==19807== by 0x80596F9: state_machine_initialize (state_machine.c:69) ==19807== by 0x8057555: a2_initialize (a2-tgdb.c:231) ==19807== by 0x8056AB1: tgdb_client_initialize_context (tgdb_client_interface.c:317) ==19807== by 0x805516D: tgdb_initialize (tgdb.c:396) ==19807== by 0x804A6E9: start_gdb (cgdb.c:320) ==19807== by 0x804B6DB: main (cgdb.c:879) ==19807== ==19807== ==19807== 7265 (516 direct, 6749 indirect) bytes in 3 blocks are definitely lost in loss record 34 of 57 ==19807== at 0x1B904F75: calloc (vg_replace_malloc.c:175) ==19807== by 0x1B969130: _nc_setupterm (in /lib/libncurses.so.5.4) ==19807== by 0x1B969C15: tgetent (in /lib/libncurses.so.5.4) ==19807== by 0x1B99E5F2: _rl_init_terminal_io (in /lib/libreadline.so.5.0) ==19807== by 0x1B98C23A: (within /lib/libreadline.so.5.0) ==19807== by 0x1B98C1A4: rl_initialize (in /lib/libreadline.so.5.0) ==19807== by 0x1B99DE38: (within /lib/libreadline.so.5.0) ==19807== by 0x80616CF: rline_initialize (rline.c:91) ==19807== by 0x804B635: init_readline (cgdb.c:858) ==19807== by 0x804B760: main (cgdb.c:896) ==19807== ==19807== ==19807== 1326 bytes in 2 blocks are possibly lost in loss record 39 of 57 ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==19807== by 0x1B96EC2E: _nc_read_file_entry (in /lib/libncurses.so.5.4) ==19807== by 0x1B96F3E3: (within /lib/libncurses.so.5.4) ==19807== by 0x1B96F460: (within /lib/libncurses.so.5.4) ==19807== by 0x1B96F641: _nc_read_entry (in /lib/libncurses.so.5.4) ==19807== by 0x1B96943C: _nc_setupterm (in /lib/libncurses.so.5.4) ==19807== by 0x1B969C15: tgetent (in /lib/libncurses.so.5.4) ==19807== by 0x1B99E5F2: _rl_init_terminal_io (in /lib/libreadline.so.5.0) ==19807== by 0x1B99E92E: rl_reset_terminal (in /lib/libreadline.so.5.0) ==19807== by 0x80616EE: rline_initialize (rline.c:96) ==19807== by 0x804B635: init_readline (cgdb.c:858) ==19807== by 0x804B760: main (cgdb.c:896) ==19807== ==19807== LEAK SUMMARY: ==19807== definitely lost: 2272 bytes in 186 blocks. ==19807== indirectly lost: 19685 bytes in 58 blocks. ==19807== possibly lost: 1326 bytes in 2 blocks. ==19807== still reachable: 233610 bytes in 2634 blocks. ==19807== suppressed: 0 bytes in 0 blocks. ==19807== Reachable blocks (those to which a pointer was found) are not shown. ==19807== To see them, rerun with: --show-reachable=yes |
|
From: Robert W. <rj...@du...> - 2005-08-13 18:34:15
|
> When I run memcheck, I get the below output. I think they are malloc > bugs because I can not reproduce them. Should this get reported to > someone? or is should I assumme everything is OK? Why do you think these are malloc bugs? These are locations in your code where you called malloc to allocate memory but subsequently never freed it. These are genuine memory leaks. What do you mean "can not reproduce them"? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Bob R. <bo...@br...> - 2005-08-14 01:05:17
|
On Sat, Aug 13, 2005 at 11:34:03AM -0700, Robert Walsh wrote: > > When I run memcheck, I get the below output. I think they are malloc > > bugs because I can not reproduce them. Should this get reported to > > someone? or is should I assumme everything is OK? > > Why do you think these are malloc bugs? These are locations in your > code where you called malloc to allocate memory but subsequently never > freed it. These are genuine memory leaks. What do you mean "can not > reproduce them"? Yeah, sorry for saying "can not reproduce them". What I mean to say is, I can not figure out how to track down the leak. Usually, I can do this very easily. For some reason, I can't do it in this case. Valgrind usually reports when the memory was leaked, right? Because the left hand side of the assignment is NULL when the malloc is done and assigns the value. How could this be a memory leak? Thanks, Bob Rossi |
|
From: Robert W. <rj...@du...> - 2005-08-14 01:39:46
|
> > Why do you think these are malloc bugs? These are locations in your > > code where you called malloc to allocate memory but subsequently never > > freed it. These are genuine memory leaks. What do you mean "can not > > reproduce them"? >=20 > Yeah, sorry for saying "can not reproduce them". What I mean to say > is, I can not figure out how to track down the leak. Usually, I can do > this very easily. For some reason, I can't do it in this case. >=20 > Valgrind usually reports when the memory was leaked, right? Because the > left hand side of the assignment is NULL when the malloc is done and > assigns the value. How could this be a memory leak? Valgrind reports where (not when) the memory that was leaked was allocated. So that malloc stack backtrace you see was an instance of some memory that was allocated but never freed. The lvalue would only factor into this if it already pointed to some allocated memory: 1: char *lv; 2: lv =3D malloc(10); 3: lv =3D malloc(10); 4: free(lv); would show up as a memory leak on line 2. Nothing would show up for line 3, which is where the leak actually happens. You can instrument your code to force Valgrind to do a leak check on the fly, which might help you track down exactly where the leak is happening. See the instructions for VALGRIND_DO_LEAK_CHECK in the user guide. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Bob R. <bo...@br...> - 2005-08-17 11:24:39
|
On Sat, Aug 13, 2005 at 06:39:38PM -0700, Robert Walsh wrote: > > > Why do you think these are malloc bugs? These are locations in your > > > code where you called malloc to allocate memory but subsequently never > > > freed it. These are genuine memory leaks. What do you mean "can not > > > reproduce them"? > > > > Yeah, sorry for saying "can not reproduce them". What I mean to say > > is, I can not figure out how to track down the leak. Usually, I can do > > this very easily. For some reason, I can't do it in this case. > > > > Valgrind usually reports when the memory was leaked, right? Because the > > left hand side of the assignment is NULL when the malloc is done and > > assigns the value. How could this be a memory leak? > > Valgrind reports where (not when) the memory that was leaked was > allocated. So that malloc stack backtrace you see was an instance of > some memory that was allocated but never freed. The lvalue would only > factor into this if it already pointed to some allocated memory: > > 1: char *lv; > 2: lv = malloc(10); > 3: lv = malloc(10); > 4: free(lv); > > would show up as a memory leak on line 2. Nothing would show up for > line 3, which is where the leak actually happens. > > You can instrument your code to force Valgrind to do a leak check on the > fly, which might help you track down exactly where the leak is > happening. See the instructions for VALGRIND_DO_LEAK_CHECK in the user > guide. Well, I finally found the memory leak. Most of the time it's much easier, but this time it was difficult. Thanks for the help. Bob Rossi |
|
From: Igmar P. <mai...@jd...> - 2005-08-15 10:06:33
|
Hi,
These are all genuine memory leaks :
> ==19807== 74 bytes in 1 blocks are definitely lost in loss record 18 of 57
> ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130)
> ==19807== by 0x80514E0: load_file (sources.c:277)
^^^^^^^^^^^^^^^^^^^^^^^^^
This is where the leak is.
> ==19807== by 0x80529A8: source_set_exec_line (sources.c:786)
> ==19807== by 0x804EC31: if_show_file (interface.c:1286)
> ==19807== by 0x804AA55: process_commands (cgdb.c:430)
> ==19807== by 0x804AC37: gdb_input (cgdb.c:539)
> ==19807== by 0x804B403: main_loop (cgdb.c:774)
> ==19807== by 0x804BA84: main (cgdb.c:967)
> ==19807==
> ==19807==
> ==19807== 413 bytes in 52 blocks are definitely lost in loss record 30 of 57
> ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130)
> ==19807== by 0x1BA23A5F: strdup (in /lib/libc-2.3.2.so)
> ==19807== by 0x80635CB: xstrdup (sys_util.c:44)
> ==19807== by 0x8063959: invoke_debugger (fork_util.c:178)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is where the leak is
> ==19807== by 0x80574EC: a2_create_context (a2-tgdb.c:208)
> ==19807== by 0x80569C3: tgdb_client_create_context (tgdb_client_interface.c:291)
> ==19807== by 0x80550FA: tgdb_initialize (tgdb.c:383)
> ==19807== by 0x804A6E9: start_gdb (cgdb.c:320)
> ==19807== by 0x804B6DB: main (cgdb.c:879)
> ==19807==
> ==19807==
> ==19807== 14205 (1269 direct, 12936 indirect) bytes in 130 blocks are definitely lost in loss record 33 of 57
> ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130)
> ==19807== by 0x806355E: xmalloc (sys_util.c:28)
> ==19807== by 0x8061936: ibuf_init (ibuf.c:16)
^^^^^^^^^^^^^^^^^^^^^
This is where the leak is.
> ==19807== by 0x80596F9: state_machine_initialize (state_machine.c:69)
> ==19807== by 0x8057555: a2_initialize (a2-tgdb.c:231)
> ==19807== by 0x8056AB1: tgdb_client_initialize_context (tgdb_client_interface.c:317)
> ==19807== by 0x805516D: tgdb_initialize (tgdb.c:396)
> ==19807== by 0x804A6E9: start_gdb (cgdb.c:320)
> ==19807== by 0x804B6DB: main (cgdb.c:879)
> ==19807==
> ==19807==
> ==19807== 7265 (516 direct, 6749 indirect) bytes in 3 blocks are definitely lost in loss record 34 of 57
> ==19807== at 0x1B904F75: calloc (vg_replace_malloc.c:175)
> ==19807== by 0x1B969130: _nc_setupterm (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B969C15: tgetent (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B99E5F2: _rl_init_terminal_io (in /lib/libreadline.so.5.0)
> ==19807== by 0x1B98C23A: (within /lib/libreadline.so.5.0)
> ==19807== by 0x1B98C1A4: rl_initialize (in /lib/libreadline.so.5.0)
> ==19807== by 0x1B99DE38: (within /lib/libreadline.so.5.0)
> ==19807== by 0x80616CF: rline_initialize (rline.c:91)
> ==19807== by 0x804B635: init_readline (cgdb.c:858)
> ==19807== by 0x804B760: main (cgdb.c:896)
This is a leak in the libedit / ncurses library. I've also seen them in my
apps, but havent't bothered to fix them.
> ==19807==
> ==19807==
> ==19807== 1326 bytes in 2 blocks are possibly lost in loss record 39 of 57
> ==19807== at 0x1B90459D: malloc (vg_replace_malloc.c:130)
> ==19807== by 0x1B96EC2E: _nc_read_file_entry (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B96F3E3: (within /lib/libncurses.so.5.4)
> ==19807== by 0x1B96F460: (within /lib/libncurses.so.5.4)
> ==19807== by 0x1B96F641: _nc_read_entry (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B96943C: _nc_setupterm (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B969C15: tgetent (in /lib/libncurses.so.5.4)
> ==19807== by 0x1B99E5F2: _rl_init_terminal_io (in /lib/libreadline.so.5.0)
> ==19807== by 0x1B99E92E: rl_reset_terminal (in /lib/libreadline.so.5.0)
> ==19807== by 0x80616EE: rline_initialize (rline.c:96)
> ==19807== by 0x804B635: init_readline (cgdb.c:858)
> ==19807== by 0x804B760: main (cgdb.c:896)
See comment above.
Igmar
|