[SR-Users] Memory leak when using db_unixodbc, help tracking it down (try 2)

[Daniel-Constantin Mierla]

Hello,

I found some cases when variables were not freed, but I cannot test as I 
am not using unixodbc.

Can you cherry pick the patch:

- 
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edc78dfb148c22f0d256485193bbdb0185b76d2f

and see if not all goes ok? If not other issues, then I will backport.

Cheers,
Daniel

On 21/03/14 17:37, Alex Villací­s Lasso wrote:
> I have a CentOS 6 installation with the following packages installed 
> from the RPM build service from Kamailio:
>
> kamailio-unixodbc-4.1.2-1.1.x86_64
> kamailio-4.1.2-1.1.x86_64
> kamailio-presence-4.1.2-1.1.x86_64
> kamailio-utils-4.1.2-1.1.x86_64
>
> I am also using db_unixodbc for all database accesses (with MySQL 
> backend). The problem is that after a few hours, a single Kamailio 
> process (never more than one) starts complaining that it has run out 
> of memory:
>
>  9(11479) ERROR: uac [uac_reg.c:638]: uac_reg_tm_callback(): got sip 
> response 408 while registering [admin_pbx.elastix.com]
>  9(11479) ERROR: db_unixodbc [dbase.c:335]: 
> db_unixodbc_fetch_result(): no memory left
>  9(11479) ERROR: <core> [db_query.c:502]: db_fetch_next(): unable to 
> fetch next rows
>  9(11479) ERROR: db_unixodbc [dbase.c:224]: db_unixodbc_free_result(): 
> invalid parameter value
>  9(11479) ERROR: db_unixodbc [dbase.c:327]: 
> db_unixodbc_fetch_result(): no private memory left
>  9(11479) ERROR: <core> [db_query.c:434]: db_fetch_query_internal(): 
> unable to fetch the db result
>  9(11479) ERROR: presence [publish.c:108]: msg_presentity_clean(): 
> failed to query database for expired messages
>  9(11479) ERROR: db_unixodbc [dbase.c:327]: 
> db_unixodbc_fetch_result(): no private memory left
>  9(11479) ERROR: <core> [db_query.c:434]: db_fetch_query_internal(): 
> unable to fetch the db result
>  9(11479) ERROR: presence [publish.c:108]: msg_presentity_clean(): 
> failed to query database for expired messages
>  9(11479) ERROR: db_unixodbc [dbase.c:327]: 
> db_unixodbc_fetch_result(): no private memory left
>  9(11479) ERROR: <core> [db_query.c:434]: db_fetch_query_internal(): 
> unable to fetch the db result
>
> I have attached the stderr output when I kill the offending process. 
> From what I can see, the memory leak somehow involves database 
> allocations that fail to be freed, consuming more than 3 MB out of 4 
> MB allocated:
>
>  9(11479) NOTICE: <core> [main.c:857]: sig_usr(): Memory still-in-use 
> summary (pkg):
>  9(11479) NOTICE: qm_sums: summarizing all alloc'ed. fragments:
>  9(11479) NOTICE: qm_sums:  count=     1 size=     10240 bytes from 
> mi_fifo: mi_writer.c: mi_writer_init(57)
>  9(11479) NOTICE: qm_sums:  count=   378 size=   3029384 bytes from 
> db_unixodbc: dbase.c: db_unixodbc_fetch_result(333)
>  9(11479) NOTICE: qm_sums:  count=     1 size=      4096 bytes from 
> db_unixodbc: dbase.c: db_unixodbc_fetch_result(325)
>  9(11479) NOTICE: qm_sums:  count=     1 size=        16 bytes from 
> <core>: sr_module.c: init_modules(1002)
>  9(11479) NOTICE: qm_sums:  count=     1 size=        56 bytes from 
> textops: textops.c: hname_fixup(1634)
>  9(11479) NOTICE: qm_sums:  count=     1 size=        32 bytes from 
> rr: rr_cb.c: register_rrcb(63)
>
> I have the setup to compile my own RPMS, and I intend to track down 
> the memory leak on my own. However, I would like your help in focusing 
> my search, on whether this is a known issue, or where in db_unixodbc 
> should I look.
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140324/cf27d4c7/attachment.html>