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_t0rhpkohrmtqebavk8gceqslkh6jvvbbpy...@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)
