[Spread-users] Another way to leak (valgrind report)

Greg Shebert gshebert at efs-us.com
Mon Aug 30 13:11:51 EDT 2004


hi folks

ran the spread daemon thru valgrind using sabuse3... here is the report:

==16335== Warning: client attempted to close Valgrind's logfile fd (2).
==16335==    Use --logfile-fd=<number> to select an alternative logfile
fd.
==16335== Syscall param socketcall.sendmsg(msg.msg_iov[i] contains
uninitialised
 or unaddressable byte(s)
==16335==    at 0x4031ABB6: __libc_sendmsg (in /lib/libc-2.3.2.so)
==16335==    by 0x805B6D2: Net_ucast_token (network.c:656)
==16335==    by 0x80582C0: Create_form1 (membership.c:1384)
==16335==    by 0x805758D: Form_or_fail (membership.c:905)
==16335==    Address 0xBFFFE170 is on thread 1's stack
==16335== discard syms in /lib/libnss_files-2.3.2.so due to munmap()
==16335== 
==16335== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==16335== malloc/free: in use at exit: 387815 bytes in 2304 blocks.
==16335== malloc/free: 19309 allocs, 17005 frees, 825392 bytes
allocated.
==16335== For counts of detected errors, rerun with: -v
==16335== searching for pointers to 2304 not-freed blocks.
==16335== checked 5148452 bytes.
==16335== 
==16335== 
==16335== 48 bytes in 5 blocks are definitely lost in loss record 2 of
12
==16335==    at 0x4002965E: malloc (vg_replace_malloc.c:153)
==16335==    by 0x402B12DF: __GI___strdup (in /lib/libc-2.3.2.so)
==16335==    by 0x805D7A3: yylex (config_gram.l:200)
==16335==    by 0x805FBF0: yyparse (y.tab.c:643)
==16335== 
==16335== 
==16335== 58 bytes in 3 blocks are possibly lost in loss record 3 of 12
==16335==    at 0x40029AD6: calloc (vg_replace_malloc.c:284)
==16335==    by 0x805586A: Mem_alloc (memory.c:536)
==16335==    by 0x80608E6: set_param_if_valid (configuration.c:577)
==16335==    by 0x80609FA: Conf_set_runtime_dir (configuration.c:605)
==16335== 
==16335== 
==16335== 80 bytes in 2 blocks are possibly lost in loss record 4 of 12
==16335==    at 0x4002965E: malloc (vg_replace_malloc.c:153)
==16335==    by 0x8060B8F: sl_init (skiplist.c:93)
==16335==    by 0x80512E4: G_handle_join (groups.c:755)
==16335==    by 0x804F6A3: Sess_handle_join (session.c:1924)
==16335== 
==16335== 
==16335== 85720 bytes in 2143 blocks are definitely lost in loss record
10 of 12
==16335==    at 0x4002965E: malloc (vg_replace_malloc.c:153)
==16335==    by 0x8060B8F: sl_init (skiplist.c:93)
==16335==    by 0x80512E4: G_handle_join (groups.c:755)
==16335==    by 0x804F6A3: Sess_handle_join (session.c:1924)
==16335== 
==16335== 
==16335== 100016 bytes in 1 blocks are possibly lost in loss record 11
of 12
==16335==    at 0x40029AD6: calloc (vg_replace_malloc.c:284)
==16335==    by 0x805545D: Mem_init_object (memory.c:332)
==16335==    by 0x804FC97: G_init (groups.c:248)
==16335==    by 0x804C638: Sess_init (session.c:434)
==16335== 
==16335== 
==16335== 168900 bytes in 139 blocks are possibly lost in loss record 12
of 12
==16335==    at 0x40029AD6: calloc (vg_replace_malloc.c:284)
==16335==    by 0x80556D2: new (memory.c:433)
==16335==    by 0x8049F3D: Prot_init (protocol.c:122)
==16335==    by 0x804C4DC: Sess_init (session.c:353)
==16335== 
==16335== LEAK SUMMARY:
==16335==    definitely lost: 85768 bytes in 2148 blocks.
==16335==    possibly lost:   269054 bytes in 145 blocks.
==16335==    still reachable: 32993 bytes in 11 blocks.
==16335==         suppressed: 0 bytes in 0 blocks.
==16335== Reachable blocks (those to which a pointer was found) are not
shown.
==16335== To see them, rerun with: --show-reachable=yes
==16335== 



On Mon, 2004-08-30 at 10:42, David Shaw wrote:
> Here's a variation on the theme of the various leak generating
> programs I've been posting.
> 
> This one is the simplest so far.  It doesn't even send any data.  All
> it does is connect to spread, and then join and leave a group over and
> over.  Membership messages are not even turned on.  It takes a while,
> but you can watch spread's memory usage go up and up until the machine
> starts swapping to death.  The memory is never returned.
> 
> David





More information about the Spread-users mailing list