Hi team, Here they are, both last time report and the one i have produced few minutes ago. Thank you. I captured in 10 & 12 minutes, interested that they have same size.
Upload again on dropbox cause my friend has deleted it: https://www.dropbox.com/s/yjrc6wmdm0rwonz/smsbox_memleakcheck_20140503.txt https://www.dropbox.com/s/f8zgfc5ji84a0n8/smsbox_memleakcheck_20140510.txt Regards, Hanh. On Fri, May 9, 2014 at 9:07 PM, <[email protected]> wrote: > Hi Hanh, > > > > Please you email us the file smsbox_memleakcheck_20140503.txt with your > results from Valgrind, as it’s no longer available on drop box. > > > > Thanks > > > > > > *From:* Alexander Malysh [mailto:[email protected]] *On Behalf Of *Alexander > Malysh > *Sent:* Friday, May 9, 2014 12:58 PM > *To:* [email protected] > *Cc:* Hanh Le Bich; [email protected]; Stipe Tolj; [email protected] > > *Subject:* Re: Does opensmppbox and smsbox have serious memory issues? > > > > Hi, > > > > unfortunately this file is not there anymore. Could you please new file > please? > > > > Alex > > > > Am 07.05.2014 um 13:15 schrieb [email protected]: > > > > HI Hanh and Kannel developers, > > > > The memory leaks in the latest svn for smsbox, as mentioned in your post > Date: Sat, 3 May 2014 10:06:54 +0700 and shown in > https://www.dropbox.com/s/yjrc6wmdm0rwonz/smsbox_memleakcheck_20140503.txt > > are also contributing to the increase in the total memory leak. Each > SMSs needs to also go through smsbox. There are memory leaks both smsbox > and also in opensmppbox. > > > > Thanks for bringing this to the attention of the Kannel devel group and > producing these Valgrinds. It’s useful to see what happens to Kannel with a > high throughput. > > This is currently not my area of expertise. > > > > We need the help of the top Kannel developers to fix this, so the latest > svn will be free of memory leaks. > > > > You mention in the post on Sat, 3 May 2014 10:06:54 +0700: “Hello again, > Here is valgrind report for the smsbox memory leaking. This is also the > latest kannel revision 5089. > > For me, it still happen, i submit (broadcast) million SMS(s) per day > within few hours at 1000 TPS of throughput. Thus each day, smsbox swallow ~ > 400MB RAM and not release until server memory exhaust after few days. At > this time, the box is auto restarted and i have my memory back, so on, > again and again. > > > > I not sure, but in very low throughput system, i am not aware this issue. > > > > ==5730== LEAK SUMMARY: > > ==5730== definitely lost: 231,680 bytes in 14,480 blocks > > ==5730== indirectly lost: 144,790 bytes in 14,479 blocks > > ==5730== possibly lost: 0 bytes in 0 blocks > > ==5730== still reachable: 1,250 bytes in 40 blocks > > ==5730== suppressed: 0 bytes in 0 blocks > > ==5730== Reachable blocks (those to which a pointer was found) are not > shown. > > ==5730== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==5730== ==5730== For counts of detected and suppressed errors, rerun with: > > -v ==5730== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from > 10)” > > > > rgds > > > > *From:* Hanh Le Bich [mailto:[email protected] <[email protected]>] > *Sent:* Wednesday, May 7, 2014 10:32 AM > *To:* Rene Kluwen > *Cc:* [email protected]; [email protected]; [email protected] > *Subject:* Re: Does opensmppbox and smsbox have serious memory issues? > > > > No Rene, i just monitor by some mem check tool. For example, htop tell me > in the fist day, opensmppbox occupied 0.1% of RAM, the next 2 day is was > 0.2%, and the 5th day, it is 0.3% now. Slowly increase. > > > > Regards, Hanh. > > > > On Wed, May 7, 2014 at 3:09 PM, Rene Kluwen <[email protected]> wrote: > > Would you happen to have a valgrind output for this? > > > > == Rene > > > > *From:* Hanh Le Bich [mailto:[email protected]] > *Sent:* woensdag 7 mei 2014 9:20 > *To:* [email protected] > *Cc:* Rene Kluwen; [email protected]; [email protected] > > > *Subject:* Re: Does opensmppbox and smsbox have serious memory issues? > > > > Hello again, > > Hope you are doing great. > After close monitoring opensmppbox after > 4 days continuous running, I > just want to inform the mem leak still happen, the box is eating few tens > (or nearly hundred) byte per day at throughput 100TPS (at max) and keep > increasing. > > Regards, Hanh. > > >
==5730== Memcheck, a memory error detector ==5730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==5730== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==5730== Command: /usr/local/sbin/smsbox -v -d -- /etc/kannel/kannel.conf ==5730== Parent PID: 5728 ==5730== ==5730== ==5730== HEAP SUMMARY: ==5730== in use at exit: 377,720 bytes in 28,999 blocks ==5730== total heap usage: 2,999,707 allocs, 2,970,708 frees, 399,074,706 bytes allocated ==5730== ==5730== 376,470 (231,680 direct, 144,790 indirect) bytes in 14,480 blocks are definitely lost in loss record 42 of 42 ==5730== at 0x4027434: malloc (vg_replace_malloc.c:291) ==5730== by 0x8081BD3: gw_native_malloc (gwmem-native.c:87) ==5730== by 0x808F091: octstr_create_from_data_real (octstr.c:263) ==5730== by 0x808F671: octstr_duplicate_real (octstr.c:377) ==5730== by 0x8056966: send_message (smsbox.c:344) ==5730== by 0x805C4D4: smsbox_req_handle (smsbox.c:2303) ==5730== by 0x805D95D: sendsms_thread (smsbox.c:2558) ==5730== by 0x8082C9E: new_thread (gwthread-pthread.c:385) ==5730== by 0x4415C38: start_thread (pthread_create.c:304) ==5730== by 0x482FD4D: clone (clone.S:130) ==5730== ==5730== LEAK SUMMARY: ==5730== definitely lost: 231,680 bytes in 14,480 blocks ==5730== indirectly lost: 144,790 bytes in 14,479 blocks ==5730== possibly lost: 0 bytes in 0 blocks ==5730== still reachable: 1,250 bytes in 40 blocks ==5730== suppressed: 0 bytes in 0 blocks ==5730== Reachable blocks (those to which a pointer was found) are not shown. ==5730== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==5730== ==5730== For counts of detected and suppressed errors, rerun with: -v ==5730== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from 10)
==8569== Memcheck, a memory error detector ==8569== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8569== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==8569== Command: /usr/local/sbin/smsbox -v -d -- /etc/kannel/kannel.conf ==8569== Parent PID: 8567 ==8569== ==8569== ==8569== HEAP SUMMARY: ==8569== in use at exit: 273,928 bytes in 21,015 blocks ==8569== total heap usage: 2,177,423 allocs, 2,156,408 frees, 287,740,658 bytes allocated ==8569== ==8569== 272,688 (167,808 direct, 104,880 indirect) bytes in 10,488 blocks are definitely lost in loss record 41 of 41 ==8569== at 0x4027434: malloc (vg_replace_malloc.c:291) ==8569== by 0x8081BD3: gw_native_malloc (gwmem-native.c:87) ==8569== by 0x808F091: octstr_create_from_data_real (octstr.c:263) ==8569== by 0x808F671: octstr_duplicate_real (octstr.c:377) ==8569== by 0x8056966: send_message (smsbox.c:344) ==8569== by 0x805C4D4: smsbox_req_handle (smsbox.c:2303) ==8569== by 0x805D95D: sendsms_thread (smsbox.c:2558) ==8569== by 0x8082C9E: new_thread (gwthread-pthread.c:385) ==8569== by 0x4415C38: start_thread (pthread_create.c:304) ==8569== by 0x482FD4D: clone (clone.S:130) ==8569== ==8569== LEAK SUMMARY: ==8569== definitely lost: 167,808 bytes in 10,488 blocks ==8569== indirectly lost: 104,880 bytes in 10,488 blocks ==8569== possibly lost: 0 bytes in 0 blocks ==8569== still reachable: 1,240 bytes in 39 blocks ==8569== suppressed: 0 bytes in 0 blocks ==8569== Reachable blocks (those to which a pointer was found) are not shown. ==8569== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==8569== ==8569== For counts of detected and suppressed errors, rerun with: -v ==8569== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 45 from 10)
