[asterisk-dev] memory leaks

[Beau Hargis]

On Fri, 2006-01-27 at 22:51 -0600, Tilghman Lesher wrote:
> On Friday 27 January 2006 00:09, Beau Hargis wrote:
> > ==30319== 2,358 (2,096 direct, 262 indirect) bytes in 131 blocks
> > are definitely lost in loss record 323 of 348
> > ==30319==    at 0x4905DA7: calloc (vg_replace_malloc.c:279)
> > ==30319==    by 0x4871D8: ast_yylex (ast_expr2.fl:84)
> > ==30319==    by 0x483AC4: ast_yyparse (ast_expr2.c:1149)
> > ==30319==    by 0x488F6E: ast_expr (ast_expr2.fl:112)
> 
> <snip>
> 
> Try updating to the latest 1.2 tree in SVN and see if you're still
> getting the same leaks.
> 

I just checked out a fresh copy of the latest branch and I get a few,
but definitely not as bad. The version of subversion on this machine was
1.1, so it is possible that it got confused about some things since I
was editing some files in the tree and adding things. I will do some
real heavy testing next week.

What I do get are some of these:

==30808== 5 errors in context 2 of 6:
==30808== Thread 5:
==30808== Invalid read of size 4
==30808==    at 0x4BF41B0: ??? (res_musiconhold.c:493)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==  Address 0x4A477BC is 66,196 bytes inside a block of size
66,208 free'd
==30808==    at 0x4905623: free (vg_replace_malloc.c:235)
==30808==    by 0x4BF3644: ??? (res_musiconhold.c:169)
==30808==    by 0x4BF5BF7: ??? (res_musiconhold.c:1085)
==30808==    by 0x45C0B0: ast_run_atexits (asterisk.c:824)
==30808==    by 0x45C2D3: quit_handler (asterisk.c:889)
==30808==    by 0x45C8E4: handle_shutdown_now (asterisk.c:1093)
==30808==    by 0x443D1F: ast_cli_command (cli.c:1364)
==30808==    by 0x45B64D: netconsole (asterisk.c:546)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==
==30808== 5 errors in context 3 of 6:
==30808== Invalid read of size 4
==30808==    at 0x4BF415E: ??? (res_musiconhold.c:486)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==  Address 0x4A477B8 is 66,192 bytes inside a block of size
66,208 free'd
==30808==    at 0x4905623: free (vg_replace_malloc.c:235)
==30808==    by 0x4BF3644: ??? (res_musiconhold.c:169)
==30808==    by 0x4BF5BF7: ??? (res_musiconhold.c:1085)
==30808==    by 0x45C0B0: ast_run_atexits (asterisk.c:824)
==30808==    by 0x45C2D3: quit_handler (asterisk.c:889)
==30808==    by 0x45C8E4: handle_shutdown_now (asterisk.c:1093)
==30808==    by 0x443D1F: ast_cli_command (cli.c:1364)
==30808==    by 0x45B64D: netconsole (asterisk.c:546)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==
==30808== 5 errors in context 4 of 6:
==30808== Invalid read of size 8
==30808==    at 0x4BF4302: ??? (res_musiconhold.c:512)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==  Address 0x4A477B0 is 66,184 bytes inside a block of size
66,208 free'd
==30808==    at 0x4905623: free (vg_replace_malloc.c:235)
==30808==    by 0x4BF3644: ??? (res_musiconhold.c:169)
==30808==    by 0x4BF5BF7: ??? (res_musiconhold.c:1085)
==30808==    by 0x45C0B0: ast_run_atexits (asterisk.c:824)
==30808==    by 0x45C2D3: quit_handler (asterisk.c:889)
==30808==    by 0x45C8E4: handle_shutdown_now (asterisk.c:1093)
==30808==    by 0x443D1F: ast_cli_command (cli.c:1364)
==30808==    by 0x45B64D: netconsole (asterisk.c:546)
==30808==    by 0x3BAF6060A9: start_thread
(in /lib64/tls/libpthread-2.3.4.so)
==30808==    by 0x3BAEDC5B42: clone (in /lib64/tls/libc-2.3.4.so)
==30808==
==30808== 10 errors in context 5 of 6:
==30808== Thread 1:
==30808== Syscall param ioctl(generic) points to uninitialised byte(s)
==30808==    at 0x3BAEDBE269: ioctl (in /lib64/tls/libc-2.3.4.so)
==30808==    by 0x64B8A98: ??? (chan_zap.c:9074)
==30808==    by 0x64BE5D7: ??? (chan_zap.c:10855)
==30808==    by 0x64BE71A: load_module (chan_zap.c:10886)
==30808==    by 0x416546: __load_resource (loader.c:413)
==30808==    by 0x416A09: load_modules (loader.c:553)
==30808==    by 0x45FE05: main (asterisk.c:2349)
==30808==  Address 0x7FF0001E0 is on thread 1's stack
==30808==
==30808== 230 errors in context 6 of 6:
==30808== Syscall param ioctl(generic) points to uninitialised byte(s)
==30808==    at 0x3BAEDBE269: ioctl (in /lib64/tls/libc-2.3.4.so)
==30808==    by 0x64B15E3: ??? (chan_zap.c:6905)
==30808==    by 0x64BBBEA: ??? (chan_zap.c:10246)
==30808==    by 0x64BE71A: load_module (chan_zap.c:10886)
==30808==    by 0x416546: __load_resource (loader.c:413)
==30808==    by 0x416A09: load_modules (loader.c:553)
==30808==    by 0x45FE05: main (asterisk.c:2349)
==30808==  Address 0x7FF000194 is on thread 1's stack

... and I dont know if it has something to do with the fact that I am
running with a 64-bit OS. I will test with a 32-bit build next week.

I do have to say that the quality of code in asterisk is far better than
I expected. Even running under valgrind with no optimizations, it was
still able to take about 50 simultaneous calls with little jitter. 

Some memory leaks are not a big deal. It just needs to stay up and
running over a 3-day weekend so the switch tech doesnt call at 2am
saying that they spans have gone RED.

Thanks.