[SR-Users] Core db_text module

Daniel-Constantin Mierla miconda at gmail.com
Fri Sep 23 13:34:42 CEST 2011


Hello,

interesting ... give also the output of:

p _tbc
p *_tbc

Cheers,
Daniel

On 9/23/11 1:27 PM, Bruno Bresciani wrote:
> Hello,
>
> Doesn't exist a exact often that the table subscriber is changed, it 
> can be changed at any time and almost always the core is generated. I 
> was thinking the same thing that you, the deletion of the table is 
> done without a lock, but the function dbt_db_get_table that call 
> dbt_db_del_table does this lock previously...
>
> Follows the output of 'bt full' from gdb:
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380, 
> sync=0) at dbt_lib.c:238
> 238     dbt_lib.c: Arquivo ou diretório não encontrado.
>         in dbt_lib.c
> (gdb) bt full
> #0  0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380, 
> sync=0) at dbt_lib.c:238
>         _tbc = (dbt_table_p) 0xb6175d20
>         hash = 6
> #1  0x008b3f38 in dbt_db_get_table (_dc=0xb60fde60, _s=0xbfc94380) at 
> dbt_lib.c:300
>         _tbc = (dbt_table_p) 0xb6175d20
>         hash = 6
> #2  0x008ae12b in dbt_query (_h=0x82e3c90, _k=0xbfc94378, _op=0x0, 
> _v=0xbfc94348, _c=0x82e3e50, _n=1, _nc=2, _o=0x0, _r=0xbfc94390) at 
> dbt_base.c:200
>         _tbc = <value optimized out>
>         _drp = <value optimized out>
>         _dres = <value optimized out>
>         lkey = <value optimized out>
>         lres = (int *) 0x0
>         _o_k = (db_key_t *) 0x0
>         _o_op = 0x0
>         _o_n = <value optimized out>
>         _o_l = <value optimized out>
>         _o_nc = <value optimized out>
> #3  0x001ae088 in digest_authenticate (msg=0x82df8f8, realm=<value 
> optimized out>, tname=<value optimized out>, 
> hftype=HDR_AUTHORIZATION_T) at authorize.c:98
>         cred = <value optimized out>
>         keys = {0x1b14c8, 0x1b14d0}
>         vals = {{type = DB1_STR, nul = 0, free = 165777064, val = 
> {int_val = 136948130, ll_val = 17316817314, double_val = 
> 8.5556445301562903e-314,
>       time_val = 136948130,
>       string_val = 0x829a9a2 "3022\", realm=\"192.168.166.199\", 
> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\", 
> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, 
> uri=\"sip:192.168.166.199\", 
> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., str_val = {
>         s = 0x829a9a2 "3022\", realm=\"192.168.166.199\", 
> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\", 
> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, 
> uri=\"sip:192.168.166.199\", 
> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., len = 4}, blob_val = {
>         s = 0x829a9a2 "3022\", realm=\"192.168.166.199\", 
> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\", 
> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, 
> uri=\"sip:192.168.166.199\", 
> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., len = 4}, 
> bitmap_val = 136948130}}, {type = DB1_STR, nul = 0, free = 8200,
>     val = {int_val = 137215560, ll_val = 64561725000, double_val = 
> 3.1897730358749953e-313, time_val = 137215560, string_val = 0x82dbe48 
> "192.168.166.199",
>       str_val = {s = 0x82dbe48 "192.168.166.199", len = 15}, blob_val 
> = {s = 0x82dbe48 "192.168.166.199", len = 15}, bitmap_val = 137215560}}}
>         result = {s = 0x0, len = 0}
>         n = <value optimized out>
>         ha1 = 
> "\000\000\000\000\220GÉ¿\000\000\000\000ï=\000\000ÒBÉ¿L\215á\t\000\000\000\000(Óà\tÔBÉ¿F\000\000\000yv¯\000L\215á\t", 
> '\0' <repeats 12 times>, 
> "ÿÿÿÿ\a\000\000\000a{¯\000^{¯\000\000\000\000\000\000\000\000\000ÿÿÿÿ+\000\000\000\000\000\000\000\001\000\000\0008DÉ¿\210\033-\bÈVÉ¿HDÉ¿&\205\017\bÈVÉ¿øø-\b8DÉ¿P\020-\b", 
> '\0' <repeats 32 times>, " 
> e¯\000TDÉ¿`ñ\000\000ÐÑ\000\000\\\222¯d\030\000\000\000\000\000\000\000»¬£\000;\216á\t 
> 1±\000\000 \000\000ÔCÉ¿8\216á\t\bÔ\r¶"...
>         h = (struct hdr_field *) 0x82e0398
>         domain = {s = 0x82dbe48 "192.168.166.199", len = 15}
>         table = {s = 0x82d8f60 "subscriber", len = 10}
>         result = (db1_res_t *) 0x0
>         ret = 0
>
>
> Best Regards
>
> 2011/9/23 Daniel-Constantin Mierla <miconda at gmail.com 
> <mailto:miconda at gmail.com>>
>
>     Hello,
>
>     can you send the output of 'bt full' from gdb?
>
>     How often the subscriber table is changed? I see in this case the
>     deletion of the table is done without a lock.
>
>     Cheers,
>     Daniel
>
>
>     On 9/22/11 9:44 PM, Bruno Bresciani wrote:
>>     Hi All,
>>
>>     Kamailio 3.1.2 generate a core in db_text module when subscriber
>>     table is updated and after this action some SIP message require
>>     authentication process...
>>
>>     Someone Can Help me to understand why this core is happening?
>>     Below  is part of kamailio's trace and gdb core too.
>>
>>
>>     Kamailio's trace:
>>
>>     *Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2327]: DEBUG: auth_db
>>     [authorize.c:239]: realm value [192.168.166.199]*
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2327]: DEBUG: auth
>>     [api.c:95]: auth: digest-algo: MD5 parsed value: 1
>>     *Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2327]: DEBUG: db_text
>>     [dbt_file.c:78]: [subscriber] was updated*
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2324]: ALERT: <core>
>>     [main.c:741]: child process 2327 exited by a signal 11
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2324]: ALERT: <core>
>>     [main.c:744]: core was generated
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2324]: INFO: <core>
>>     [main.c:756]: INFO: terminating due to SIGCHLD
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2335]: INFO: <core>
>>     [main.c:807]: INFO: signal 15 received c
>>     Sep 22 16:35:54 sswpst00
>>     /home2/local/kamailio/sbin/kamailio[2335]: DEBUG: <core>
>>     [main.c:818]: Memory status (pkg):
>>
>>     gdb core trace:
>>
>>     Core was generated by `/home2/local/kamailio/sbin/kamailio -P
>>     /var/run/kamailio.pid'.
>>     Program terminated with signal 11, Segmentation fault.
>>     *#0  0x00f21603 in dbt_db_del_table (_dc=0xb6071e60,
>>     _s=0xbf837040, sync=0) at dbt_lib.c:238*
>>     238     dbt_lib.c: Arquivo ou diretório não encontrado.
>>             in dbt_lib.c
>>
>>
>>     Best Regards
>>
>>
>>     _______________________________________________
>>     SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>     sr-users at lists.sip-router.org  <mailto: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
>     Kamailio Advanced Training, Oct 10-13, Berlin:http://asipto.com/u/kat
>     http://linkedin.com/in/miconda  -- http://twitter.com/miconda
>
>
>
>
> _______________________________________________
> 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
> Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
> http://linkedin.com/in/miconda -- http://twitter.com/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110923/e3954f81/attachment-0001.htm>


More information about the sr-users mailing list