Core dump at db_unixodbc

[syco]

Hi, I'm using centos 6.5, opensips from git, everything up to date.
I configured usrloc (and all the other modules) to use unixodbc.
Here is an example of the configuration:
loadmodule "usrloc.so"
modparam("usrloc", "db_url", "unixodbc://opensips:opensipsrw@localhost/OpenSIPS")
modparam("usrloc", "db_mode", 1)

the result is a core dump:
Jul 15 09:22:51 opensips0 kernel: opensips[8177] general protection ip:4a073b sp:7fffcd229720 error:0 in opensips[400000+153000]
Jul 15 09:22:51 opensips0 abrt[8179]: Not saving repeating crash in '/usr/sbin/opensips'
Jul 15 09:22:51 opensips0 abrt[8179]: Saved core dump of pid 8177 to core.8177 (52912128 bytes)
Jul 15 09:22:51 opensips0 opensips: INFO:core:daemonize: pre-daemon process exiting with -1

Here you can see the backtrace: http://pastebin.com/xeeu25ne
For now I solved with this small patch http://pastebin.com/nzTwikcJ
I let it run 2 days, haven't noticed anything wrong with it, but please let me know if you think I'm breaking some other functionality I'm not aware of.
Thanks.

[liviuchircu]

Seems to be directly related to commit d63ee19

[liviuchircu]

Your fix looks to be leaking pkg memory in time. Would you mind applying this patch instead, and see if you can replicate the crash? Thank you

[syco]

Hi, it still crashes, I applied the patch to a clean checkout.
Can I use 1.11.2 for future tests?

(gdb) bt
#0  fm_free (qm=0x7fa1632c7010, p=0x7fa100000008) at mem/f_malloc.c:465
#1  0x00007fa1630bc209 in db_unixodbc_list_destroy (start=0x7fa1632d8018) at list.c:144
#2  0x00007fa1630bb89b in db_unixodbc_free_result (_h=0x7fa1632d71d8, _r=<value optimized out>) at dbase.c:252
#3  0x00007fa161940a3a in testdb_udomain (con=0x7fa1632d71d8, d=<value optimized out>) at udomain.c:719
#4  0x00007fa161935a08 in register_udomain (_n=<value optimized out>, _d=0x7ffffb5f1788) at dlist.c:599
#5  0x00007fa161717587 in domain_fixup (param=0x7fa1632d3ed8) at reg_mod.c:374
#6  0x000000000048fbd5 in fix_actions (a=<value optimized out>) at route.c:460
#7  0x0000000000492786 in fix_expr (exp=<value optimized out>) at route.c:216
#8  0x000000000048fc73 in fix_actions (a=<value optimized out>) at route.c:383
#9  0x00000000004906db in fix_actions (a=<value optimized out>) at route.c:387
#10 0x0000000000492a66 in fix_rls () at route.c:2038
#11 0x00000000004396fe in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1629

[liviuchircu]

Yes, you can use 1.11.2 - unixodbc code has not changed.

Funny how the problem is still at line #144 (it may be possible, though). I've changed the gist patch, so no more confusion is created. Could you please re-check? Thank you

[syco]

Done, always with git version. Error moved to line 145, so it's "pkg_free(temp->lengths);" that was causing problems after the first patch.

(gdb) bt
#0  fm_free (qm=0x7f75ab0df010, p=0x7f7500000008) at mem/f_malloc.c:465
#1  0x00007f75aaed4209 in db_unixodbc_list_destroy (start=0x7f75ab0f0018) at list.c:145
#2  0x00007f75aaed389b in db_unixodbc_free_result (_h=0x7f75ab0ef1d8, _r=<value optimized out>) at dbase.c:252
#3  0x00007f75a9758a3a in testdb_udomain (con=0x7f75ab0ef1d8, d=<value optimized out>) at udomain.c:719
#4  0x00007f75a974da08 in register_udomain (_n=<value optimized out>, _d=0x7fff71d75198) at dlist.c:599
#5  0x00007f75a952f587 in domain_fixup (param=0x7f75ab0ebed8) at reg_mod.c:374
#6  0x000000000048fbd5 in fix_actions (a=<value optimized out>) at route.c:460
#7  0x0000000000492786 in fix_expr (exp=<value optimized out>) at route.c:216
#8  0x000000000048fc73 in fix_actions (a=<value optimized out>) at route.c:383
#9  0x00000000004906db in fix_actions (a=<value optimized out>) at route.c:387
#10 0x0000000000492a66 in fix_rls () at route.c:2038
#11 0x00000000004396fe in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1629

[liviuchircu]

It is baffling how free(data) works, yet free(lengths) fails, since they were allocated in the same way and place. Moreover, I've found even more problems with the module (e.g. memory corruption at res.c +185).

It looks like the module needs a complete code audit. I will do it, and also return with a fully tested patch (somewhere around tomorrow).

[syco]

Hi,
do you have any news on this bug?
Thanks.

[liviuchircu]

Sorry for completely not responding to this... I kept postponing it because I knew you had a temporary fix. I will try to make some progress in the upcoming days.

[syco]

I'm using mysql for the time being, I'll give it a go when you have some
changes, thanks.

Alberto Rinaudo

• mobile (UK): +44 (0) 74 1496 5674 e-mail: alberto.rinaudo@gmail.com
  alberto.rinaudo@gmail.com skype: a.rinaudo *

On 24 September 2014 16:43, Liviu Chircu notifications@github.com wrote:

Sorry for completely not responding to this... I kept postponing it
because I knew you had a temporary fix. I will try to make some progress in
the upcoming days.

—
Reply to this email directly or view it on GitHub
#270 (comment).

[liviuchircu]

It seems the patch was incomplete - it led to a double free() because I was not zeroing a freed pointer. On top of that, I've done a partial rework of the internal logic in 683dfaa.

It would be great if you could test it out as well (it behaved nicely on my setup). If anything goes wrong, feel free to re-open this. Thanks!

Liviu