Re: Does opensmppbox and smsbox have serious memory issues?

Hi,
Just a notice that my opensmppbox used to run on another server, not
related to SMS Broadcast server which has smsbox "issue".
The server which run opensmppbox is a good one, but last week, i also
migrated it to another model server (still a physical one).
Here is the valgrind report for opensmppbox running on the new server, the
leaking is true:

https://www.dropbox.com/s/dnvs20j3omo7ail/opensmppbox_memleakcheck_20140608.txt

==26926== LEAK SUMMARY:
==26926==    definitely lost: 7,104 bytes in 207 blocks
==26926==    indirectly lost: 3,652 bytes in 208 blocks
==26926==      possibly lost: 8,640 bytes in 30 blocks
==26926==    still reachable: 7,516,113 bytes in 30,609 blocks
==26926==         suppressed: 0 bytes in 0 blocks
==26926== Reachable blocks (those to which a pointer was found) are not shown.
==26926== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26926==
==26926== For counts of detected and suppressed errors, rerun with: -v
==26926== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 6 from 4)

Regards,

Hanh.





On Sun, Jun 8, 2014 at 3:35 AM, <[email protected]> wrote:

> Hi Hanh,
>
> That's good news. As it seemed strange no one else would have picked up
> this
> issue for smsbox, which is so well used.
>
> However for opensmppbox, which is not as well used as smsbox, there may
> still be actual memory leaks.
> Please check again using your new virtual machine and send us your results
> using:
> valgrind --leak-check=full --track-origins=yes ./opensmppbox
>
> thanks
>
> ----------------------------------------------------------------------
> Date: Sat, 7 Jun 2014 10:31:18 +0700
> From: Hanh Le Bich <[email protected]>
> To: Stipe Tolj <[email protected]>
> Cc: [email protected]
> Subject: Re: Does opensmppbox and smsbox have serious memory issues?
> Message-ID:
>         <
> CA+p4DGyjy-26_T0rhPKOHrmtQEBAvk8GcEqSLKh6JVVBBpypGw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Stipe and list,
> I don't know how to say now. I had migrated my SMS Broadcast system to
> another server last week (an Virtual machine) and there is no mem leak of
> smsbox  any more.
> I've tested for every scenarios and it is clean:
>
> ==22709== Memcheck, a memory error detector ==22709== Copyright (C)
> 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==22709== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==22709== Command: /usr/local/sbin/smsbox -v -d -- /etc/kannel/kannel.conf
> ==22709== Parent PID: 22707 ==22709== ==22709== ==22709== HEAP SUMMARY:
> ==22709==     in use at exit: 2,184 bytes in 39 blocks
> ==22709==   total heap usage: 3,084,394 allocs, 3,084,355 frees,
> 630,991,485 bytes allocated
> ==22709==
> ==22709== LEAK SUMMARY:
> ==22709==    definitely lost: 0 bytes in 0 blocks
> ==22709==    indirectly lost: 0 bytes in 0 blocks
> ==22709==      possibly lost: 0 bytes in 0 blocks
> ==22709==    still reachable: 2,184 bytes in 39 blocks
> ==22709==         suppressed: 0 bytes in 0 blocks
> ==22709== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==22709== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==22709== ==22709== For counts of detected and suppressed errors, rerun
> with: -v ==22709== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6
> from 4)
>
> Suppose that i have physical mem issue in my old machine(!?), cause in
> migration progress, i found the old one has an alarm at its booting time:
> "8601: All memory marked as fail. Forcing minimum back online." Then i have
> to press F1 to Resume.
>
> I apology and appreciate all of you to spending time on this issue. If have
> any request for testing in high loading, also  the opensmppbox mem leak,
> please let me know. Thank you.
>
> Regards,
> Hanh.
>
>
> On Mon, Jun 2, 2014 at 8:48 PM, Stipe Tolj <[email protected]> wrote:
>
> > Am 20.05.2014 04:54, schrieb Hanh Le Bich:
> >
> >  Hello again,
> >> Sorry for late reply, i was stuck on field.
> >>
> >> 1. I upload again the previous Valgrind report in below link also in
> >> attachment as usual:
> >> https://www.dropbox.com/s/wbnkewitosiwv5i/opensmppbox_
> >> memleakcheck_20140502.txt
> >>
> >> 2. Here is my kannel configuration:
> >> https://www.dropbox.com/s/u90vs8srbubbmhn/kannel_configuration_file.t
> >> xt
> >>
> >
> > Hi list,
> >
> > I can't reproduce the memory leak that Hanh is reporting here, even
> > with setting 'smsbox-id' in the 'group = smsbox' context I get clean
> > memory deallocations.
> >
> > Here is my valgrind report:
> >
> > ==00:00:00:00.000 14193== Memcheck, a memory error detector.
> > ==00:00:00:00.000 14193== Copyright (C) 2002-2007, and GNU GPL'd, by
> > Julian Seward et al.
> > ==00:00:00:00.000 14193== Using LibVEX rev 1854, a library for dynamic
> > binary translation.
> > ==00:00:00:00.000 14193== Copyright (C) 2004-2007, and GNU GPL'd, by
> > OpenWorks LLP.
> > ==00:00:00:00.000 14193== Using valgrind-3.3.1-Debian, a dynamic
> > binary instrumentation framework.
> > ==00:00:00:00.000 14193== Copyright (C) 2000-2007, and GNU GPL'd, by
> > Julian Seward et al.
> > ==00:00:00:00.000 14193== For more details, rerun with: -v
> > ==00:00:00:00.000 14193==
> > ==00:00:00:00.000 14193== My PID = 14193, parent PID = 1.  Prog and
> > args
> > are:
> > ==00:00:00:00.000 14193== /home/tolj/src/kannel/devel/
> > gateway-redis/gw/smsbox
> > ==00:00:00:00.000 14193==    -v
> > ==00:00:00:00.000 14193==    4
> > ==00:00:00:00.000 14193==    -p
> > ==00:00:00:00.000 14193==    /opt/kannel/var/run/smsbox_client.pid
> > ==00:00:00:00.000 14193==    /opt/kannel/etc/kannel_client.conf
> > ==00:00:00:00.000 14193==
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== FILE DESCRIPTORS: 6 open at exit.
> > ==00:00:05:18.814 14193== Open file descriptor 6:
> > ==00:00:05:18.814 14193==    at 0x71E2377: pipe (in /usr/lib/debug/
> > libc-2.7.so)
> > ==00:00:05:18.814 14193==    by 0x437A2E: fill_threadinfo
> > (gwthread-pthread.c:186)
> > ==00:00:05:18.814 14193==    by 0x437D0D: gwthread_init
> > (gwthread-pthread.c:281)
> > ==00:00:05:18.814 14193==    by 0x4371D9: gwlib_init (gwlib.c:85)
> > ==00:00:05:18.814 14193==    by 0x40FC5C: main (smsbox.c:3543)
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== Open file descriptor 5:
> > ==00:00:05:18.814 14193==    at 0x71E2377: pipe (in /usr/lib/debug/
> > libc-2.7.so)
> > ==00:00:05:18.814 14193==    by 0x437A2E: fill_threadinfo
> > (gwthread-pthread.c:186)
> > ==00:00:05:18.814 14193==    by 0x437D0D: gwthread_init
> > (gwthread-pthread.c:281)
> > ==00:00:05:18.814 14193==    by 0x4371D9: gwlib_init (gwlib.c:85)
> > ==00:00:05:18.814 14193==    by 0x40FC5C: main (smsbox.c:3543)
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== Open file descriptor 3:
> > /opt/kannel-1.5.0-svn/log.valgrind
> > ==00:00:05:18.814 14193==    <inherited from parent>
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== Open file descriptor 2: /dev/null
> > ==00:00:05:18.814 14193==    <inherited from parent>
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== Open file descriptor 1: /dev/null
> > ==00:00:05:18.814 14193==    <inherited from parent>
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== Open file descriptor 0: /dev/null
> > ==00:00:05:18.814 14193==    <inherited from parent>
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193==
> > ==00:00:05:18.814 14193== ERROR SUMMARY: 0 errors from 0 contexts
> > (suppressed: 8 from 1)
> > ==00:00:05:18.814 14193== malloc/free: in use at exit: 1,840 bytes in
> > 27 blocks.
> > ==00:00:05:18.814 14193== malloc/free: 2,525,985 allocs, 2,525,958
> > frees,
> > 325,327,112 bytes allocated.
> > ==00:00:05:18.814 14193== For counts of detected errors, rerun with:
> > -v
> > ==00:00:05:18.814 14193== searching for pointers to 27 not-freed blocks.
> > ==00:00:05:18.832 14193== checked 1,748,080 bytes.
> > ==00:00:05:18.832 14193==
> > ==00:00:05:18.832 14193== LEAK SUMMARY:
> > ==00:00:05:18.832 14193==    definitely lost: 0 bytes in 0 blocks.
> > ==00:00:05:18.832 14193==      possibly lost: 0 bytes in 0 blocks.
> > ==00:00:05:18.832 14193==    still reachable: 0 bytes in 0 blocks.
> > ==00:00:05:18.832 14193==         suppressed: 1,840 bytes in 27 blocks.
> >
> > anyone being able to reproduce the leak? Please report.
> >
> > Stipe
> >
> > --
> > -------------------------------------------------------------------
> > K?lner Landstrasse 419
> > 40589 D?sseldorf, NRW, Germany
> >
> > tolj.org system architecture      Kannel Software Foundation (KSF)
> > http://www.tolj.org/              http://www.kannel.org/
> >
> > mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
> > -------------------------------------------------------------------
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> http://www.kannel.org/pipermail/devel/attachments/20140607/bbc2b334/attachm
> ent-0001.html>
>
>
>
>

==26926== Memcheck, a memory error detector
==26926== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26926== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==26926== Command: /usr/local/sbin/opensmppbox -v -d -- /etc/kannel/opensmppbox.conf
==26926== Parent PID: 26924
==26926== 
==26926== 
==26926== HEAP SUMMARY:
==26926==     in use at exit: 7,535,509 bytes in 31,054 blocks
==26926==   total heap usage: 808,481 allocs, 777,427 frees, 408,166,966 bytes allocated
==26926== 
==26926== 40 (32 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 407 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x410B80: smpp_to_bearerbox (opensmppbox.c:1569)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 160 (128 direct, 32 indirect) bytes in 4 blocks are definitely lost in loss record 513 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x440B51: cfg_get_real (cfg.c:670)
==26926==    by 0x40CDF3: main (opensmppbox.c:2292)
==26926== 
==26926== 288 bytes in 1 blocks are possibly lost in loss record 541 of 734
==26926==    at 0x4C27013: calloc (vg_replace_malloc.c:618)
==26926==    by 0x401128E: _dl_allocate_tls (dl-tls.c:300)
==26926==    by 0x6163483: pthread_create@@GLIBC_2.2.5 (allocatestack.c:580)
==26926==    by 0x5C6E8E8: my_thread_global_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0)
==26926==    by 0x5C6C527: my_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0)
==26926==    by 0x5C47D25: mysql_server_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0)
==26926==    by 0x5C4DFDE: mysql_init (in /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0)
==26926==    by 0x44952B: mysql_open_conn (dbpool_mysql.c:84)
==26926==    by 0x44982D: dbpool_increase (dbpool.c:200)
==26926==    by 0x44994E: dbpool_create (dbpool.c:166)
==26926==    by 0x414BD0: dlr_init_mysql (dlr_mysql.c:452)
==26926==    by 0x412700: dlr_init (dlr.c:257)
==26926== 
==26926== 656 (512 direct, 144 indirect) bytes in 16 blocks are definitely lost in loss record 591 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x40E953: run_smppbox (opensmppbox.c:2106)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 1,464 (672 direct, 792 indirect) bytes in 6 blocks are definitely lost in loss record 639 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x45448A: gwlist_create_real (list.c:131)
==26926==    by 0x4193C6: sms_split (sms.c:339)
==26926==    by 0x40F274: run_smppbox (opensmppbox.c:1008)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 2,089 (1,824 direct, 265 indirect) bytes in 57 blocks are definitely lost in loss record 654 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x416E83: msg_duplicate (msg-decl.h:80)
==26926==    by 0x4103DF: catenate_msg (opensmppbox.c:525)
==26926==    by 0x4106F9: check_multipart (opensmppbox.c:1481)
==26926==    by 0x411878: smpp_to_bearerbox (opensmppbox.c:1639)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 2,212 (1,984 direct, 228 indirect) bytes in 62 blocks are definitely lost in loss record 658 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x417074: msg_duplicate (msg-decl.h:80)
==26926==    by 0x4103DF: catenate_msg (opensmppbox.c:525)
==26926==    by 0x4106F9: check_multipart (opensmppbox.c:1481)
==26926==    by 0x411878: smpp_to_bearerbox (opensmppbox.c:1639)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 4,032 bytes in 14 blocks are possibly lost in loss record 680 of 734
==26926==    at 0x4C27013: calloc (vg_replace_malloc.c:618)
==26926==    by 0x401128E: _dl_allocate_tls (dl-tls.c:300)
==26926==    by 0x6163483: pthread_create@@GLIBC_2.2.5 (allocatestack.c:580)
==26926==    by 0x44C1C8: gwthread_create_real (gwthread-pthread.c:475)
==26926==    by 0x40D490: main (opensmppbox.c:2157)
==26926== 
==26926== 4,135 (1,952 direct, 2,183 indirect) bytes in 61 blocks are definitely lost in loss record 681 of 734
==26926==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==26926==    by 0x44B4C0: gw_native_malloc (gwmem-native.c:87)
==26926==    by 0x457164: octstr_create_from_data_real (octstr.c:263)
==26926==    by 0x4576C2: octstr_duplicate_real (octstr.c:377)
==26926==    by 0x416FE4: msg_duplicate (msg-decl.h:80)
==26926==    by 0x4103DF: catenate_msg (opensmppbox.c:525)
==26926==    by 0x4106F9: check_multipart (opensmppbox.c:1481)
==26926==    by 0x411878: smpp_to_bearerbox (opensmppbox.c:1639)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== 4,320 bytes in 15 blocks are possibly lost in loss record 682 of 734
==26926==    at 0x4C27013: calloc (vg_replace_malloc.c:618)
==26926==    by 0x401128E: _dl_allocate_tls (dl-tls.c:300)
==26926==    by 0x6163483: pthread_create@@GLIBC_2.2.5 (allocatestack.c:580)
==26926==    by 0x44C1C8: gwthread_create_real (gwthread-pthread.c:475)
==26926==    by 0x40E9AA: run_smppbox (opensmppbox.c:2125)
==26926==    by 0x44C5F5: new_thread (gwthread-pthread.c:385)
==26926==    by 0x6162B4F: start_thread (pthread_create.c:304)
==26926==    by 0x6CF90EC: clone (clone.S:112)
==26926== 
==26926== LEAK SUMMARY:
==26926==    definitely lost: 7,104 bytes in 207 blocks
==26926==    indirectly lost: 3,652 bytes in 208 blocks
==26926==      possibly lost: 8,640 bytes in 30 blocks
==26926==    still reachable: 7,516,113 bytes in 30,609 blocks
==26926==         suppressed: 0 bytes in 0 blocks
==26926== Reachable blocks (those to which a pointer was found) are not shown.
==26926== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26926== 
==26926== For counts of detected and suppressed errors, rerun with: -v
==26926== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 6 from 4)