Package: isns
Version: 2.1-01+dfsg-3
Severity: important
Tags: patch

*** Please type your report below this line ***

Running isnsd on a memory constraied system I found it, after running for a 
while, consumed most of the system's memory and triggered the OOM killer, 
either killing isnsd or somthing else important.

Running valgrind on isnsd and running three queries (isnsadm -a localhost -q 
{dd,dds,iscsi}) shows there are several problems:

valgrind --leak-check=full ./isnsd -f
==2344== Memcheck, a memory error detector
==2344== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2344== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==2344== Command: ./isnsd -f
==2344== 
Info: src/iSNSMain.c:145        started IETF iSNS Open Source, v2.1.1.
==2344== Conditional jump or move depends on uninitialised value(s)
==2344==    at 0x5346939: inet_addr (inet_addr.c:138)
==2344==    by 0x403DA6: SNSCommInit (iSNScomm.c:229)
==2344==    by 0x4053CC: SNSInit (iSNSInit.c:94)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== Thread 8:
==2344== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==2344==    at 0x4E3BF93: ??? (syscall-template.S:82)
==2344==    by 0x41C246: SendIPCMessage (iSNSipc.c:128)
==2344==    by 0x41C7EA: TCP_RecvThread (iSNStrcv.c:263)
==2344==    by 0x4E339C9: start_thread (pthread_create.c:300)
==2344==    by 0x93E570F: ???
==2344==  Address 0x93e2604 is on thread 8's stack
==2344== 
^C==2344== 
==2344== HEAP SUMMARY:
==2344==     in use at exit: 1,003,676 bytes in 680 blocks
==2344==   total heap usage: 743 allocs, 63 frees, 1,017,659 bytes allocated
==2344== 
==2344== Thread 1:
==2344== 5 bytes in 1 blocks are definitely lost in loss record 1 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x41EE47: GetNextNode (iSNSList.c:631)
==2344==    by 0x40DFDF: ISNSdbProcessDDSOpAttr (iSNSquery.c:2253)
==2344==    by 0x40E13D: SNSdbGetAttrDDSEntry (iSNSquery.c:487)
==2344==    by 0x4125D0: ISNSdbGetAttr (iSNSquery.c:594)
==2344==    by 0x402D2C: SNSMain (iSNSMain.c:335)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 26 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x4023EB: SNSMain (iSNSMain.c:148)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 27 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x41D664: LinuxTaskSpawn (iSNSLinux.c:145)
==2344==    by 0x4053F7: SNSInit (iSNSInit.c:120)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 28 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x41DB03: SNSStartFSM (iSNSfsm.c:313)
==2344==    by 0x405435: SNSInit (iSNSInit.c:140)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 29 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x41DB18: SNSStartFSM (iSNSfsm.c:316)
==2344==    by 0x405435: SNSInit (iSNSInit.c:140)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 30 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x41DB2D: SNSStartFSM (iSNSfsm.c:319)
==2344==    by 0x405435: SNSInit (iSNSInit.c:140)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 272 bytes in 1 blocks are possibly lost in loss record 31 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x4012465: _dl_allocate_tls (dl-tls.c:300)
==2344==    by 0x4E34728: pthread_create@@GLIBC_2.2.5 (allocatestack.c:561)
==2344==    by 0x4024B1: SNSMain (iSNSMain.c:184)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 324 bytes in 3 blocks are definitely lost in loss record 32 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x402531: SNSMain (iSNSMain.c:253)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 58 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A707: ISNSdbRead (iSNSdb.c:125)
==2344==    by 0x420989: read_DDSObject (iSNSobjects.c:211)
==2344==    by 0x412FB1: Create_Default_DD (iSNSreg.c:3411)
==2344==    by 0x405407: SNSInit (iSNSInit.c:137)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 59 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A426: ISNSdbRead (iSNSdb.c:139)
==2344==    by 0x420A09: read_DDObject (iSNSobjects.c:191)
==2344==    by 0x413031: Create_Default_DD (iSNSreg.c:3438)
==2344==    by 0x405407: SNSInit (iSNSInit.c:137)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 60 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A426: ISNSdbRead (iSNSdb.c:139)
==2344==    by 0x420A09: read_DDObject (iSNSobjects.c:191)
==2344==    by 0x40DDC4: SNSdbGetAttrDDEntry (iSNSquery.c:623)
==2344==    by 0x4121C7: ISNSdbGetAttr (iSNSquery.c:756)
==2344==    by 0x402D2C: SNSMain (iSNSMain.c:335)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 61 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A707: ISNSdbRead (iSNSdb.c:125)
==2344==    by 0x420989: read_DDSObject (iSNSobjects.c:211)
==2344==    by 0x40E127: SNSdbGetAttrDDSEntry (iSNSquery.c:483)
==2344==    by 0x4125D0: ISNSdbGetAttr (iSNSquery.c:594)
==2344==    by 0x402D2C: SNSMain (iSNSMain.c:335)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 62 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A27C: ISNSdbRead (iSNSdb.c:308)
==2344==    by 0x41EE2E: GetNextNode (iSNSList.c:627)
==2344==    by 0x40DFDF: ISNSdbProcessDDSOpAttr (iSNSquery.c:2253)
==2344==    by 0x40E13D: SNSdbGetAttrDDSEntry (iSNSquery.c:487)
==2344==    by 0x4125D0: ISNSdbGetAttr (iSNSquery.c:594)
==2344==    by 0x402D2C: SNSMain (iSNSMain.c:335)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,336 bytes in 1 blocks are definitely lost in loss record 63 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504C1FE: gdbm_fetch (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40A426: ISNSdbRead (iSNSdb.c:139)
==2344==    by 0x420A09: read_DDObject (iSNSobjects.c:191)
==2344==    by 0x40DF9A: ISNSdbProcessDDSOpAttr (iSNSquery.c:2259)
==2344==    by 0x40E13D: SNSdbGetAttrDDSEntry (iSNSquery.c:487)
==2344==    by 0x4125D0: ISNSdbGetAttr (iSNSquery.c:594)
==2344==    by 0x402D2C: SNSMain (iSNSMain.c:335)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 1,340 bytes in 1 blocks are possibly lost in loss record 65 of 85
==2344==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==2344==    by 0x504DEB7: _gdbm_read_entry (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x504CBA7: ??? (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x504CCB8: gdbm_firstkey (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40865B: SNSdbGetNextOfKey (iSNSdb.c:788)
==2344==    by 0x412FDB: Create_Default_DD (iSNSreg.c:3409)
==2344==    by 0x405407: SNSInit (iSNSInit.c:137)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== 101,376 bytes in 99 blocks are possibly lost in loss record 79 of 85
==2344==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==2344==    by 0x504B88F: _gdbm_init_cache (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x504D61F: _gdbm_get_bucket (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x504CCA4: gdbm_firstkey (in /usr/lib/libgdbm.so.3.0.0)
==2344==    by 0x40865B: SNSdbGetNextOfKey (iSNSdb.c:788)
==2344==    by 0x412FDB: Create_Default_DD (iSNSreg.c:3409)
==2344==    by 0x405407: SNSInit (iSNSInit.c:137)
==2344==    by 0x402400: SNSMain (iSNSMain.c:151)
==2344==    by 0x41D40F: main (iSNSLinux.c:253)
==2344== 
==2344== LEAK SUMMARY:
==2344==    definitely lost: 8,345 bytes in 10 blocks
==2344==    indirectly lost: 0 bytes in 0 blocks
==2344==      possibly lost: 104,348 bytes in 106 blocks
==2344==    still reachable: 890,983 bytes in 564 blocks
==2344==         suppressed: 0 bytes in 0 blocks
==2344== Reachable blocks (those to which a pointer was found) are not shown.
==2344== To see them, rerun with: --leak-check=full --show-reachable=yes
==2344== 
==2344== For counts of detected and suppressed errors, rerun with: -v
==2344== Use --track-origins=yes to see where uninitialised values come from
==2344== ERROR SUMMARY: 20 errors from 18 contexts (suppressed: 4 from 4)
Killed



The worst of these leaks (the ones that loose 1336 byes in the Valgrind output) 
are triggered with each query and consumes quite a bit of memory. As far as I 
can see it is easily solved by freeing the buffer gdbm allocates after it is 
used:

--- a/isnsserver/src/iSNSdb.c   2010-05-16 19:36:21.307283687 +0200
+++ b/isnsserver/src/iSNSdb.c   2010-05-16 17:47:10.000000000 +0200
@@ -320,6 +320,8 @@
        break;
    }
 
+   ISNSFreeBuffer(d.dptr);
+
    if (entry->data_type != key->tag)
    {    
           __LOG_ERROR ("Invalid record type:%i read from database 
key->tag:%i",entry->data_type,key->tag);


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.26-2-orion5x
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages isns depends on:
ii  libc6                       2.7-18lenny2 GNU C Library: Shared libraries
ii  libgdbm3                    1.8.3-3      GNU dbm database routines (runtime

isns recommends no packages.

isns suggests no packages.

-- no debconf information



-- 
Ørjan Eide



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to