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

Alex Villací­s Lasso a_villacis at palosanto.com
Fri Mar 21 17:37:44 CET 2014


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140321/f6e55183/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kamailio-stderr.txt.gz
Type: application/x-gzip
Size: 35287 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140321/f6e55183/attachment-0001.bin>


More information about the sr-users mailing list