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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
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@gmail.com mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@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
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
Best Regards
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
On 9/23/11 1:57 PM, Bruno Bresciani wrote:
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
run these commands inside gdb.
Daniel
Best Regards
2011/9/23 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>
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 <tel: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@gmail.com <mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Follows the output:
*p _tbc* $1 = (dbt_table_p) 0xb6175d20
*(gdb) p *_tbc* $312 = {dbname = {s = 0xb616d780 "/axs/cfg/db_text", len = 16}, name = {s = 0xb616e288 "subscriber", len = 10}, hash = 6, mark = 1316722939, flag = 0, auto_col = -1, auto_val = 0, nrcols = 10, cols = 0xb616f310, colv = 0xb6175e70, nrrows = 58, rows = 0xb616e940, mt = 1316722962, next = 0x0, prev = 0x4c58586e}
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
On 9/23/11 1:57 PM, Bruno Bresciani wrote:
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
run these commands inside gdb.
Daniel
Best Regards
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
thanks, the only possibility then is that the previous item in the list of tables has something wrong in it, send also the output for:
p *_tbc->prev
Actually, from now I see the _tmb->prev is 0x4c58586e and _tbc is 0xb6175d20, so the pointers are in different memory zones, it could be pkg one and shm the other. But lets see first the output of p *_tbc->prev
Cheers, Daniel
On 9/23/11 2:11 PM, Bruno Bresciani wrote:
Follows the output:
*p _tbc* $1 = (dbt_table_p) 0xb6175d20
*(gdb) p *_tbc* $312 = {dbname = {s = 0xb616d780 "/axs/cfg/db_text", len = 16}, name = {s = 0xb616e288 "subscriber", len = 10}, hash = 6, mark = 1316722939, flag = 0, auto_col = -1, auto_val = 0, nrcols = 10, cols = 0xb616f310, colv = 0xb6175e70, nrrows = 58, rows = 0xb616e940, mt = 1316722962, next = 0x0, prev = 0x4c58586e}
2011/9/23 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>
On 9/23/11 1:57 PM, Bruno Bresciani wrote:Sorry... but I didn't understand how I get the output of: p _tbc p *_tbcrun these commands inside gdb. DanielBest Regards 2011/9/23 Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> 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 <tel: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@gmail.com <mailto:miconda@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org <mailto:sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
Follows the output of *p *_tbc->prev*:
(gdb) p *_tbc->prev Cannot access memory at address 0x4c58586e
Best Regards
2011/9/24 Daniel-Constantin Mierla miconda@gmail.com
Hello,
thanks, the only possibility then is that the previous item in the list of tables has something wrong in it, send also the output for:
p *_tbc->prev
Actually, from now I see the _tmb->prev is 0x4c58586e and _tbc is 0xb6175d20, so the pointers are in different memory zones, it could be pkg one and shm the other. But lets see first the output of p *_tbc->prev
Cheers, Daniel
On 9/23/11 2:11 PM, Bruno Bresciani wrote:
Follows the output:
*p _tbc* $1 = (dbt_table_p) 0xb6175d20
*(gdb) p *_tbc* $312 = {dbname = {s = 0xb616d780 "/axs/cfg/db_text", len = 16}, name = {s = 0xb616e288 "subscriber", len = 10}, hash = 6, mark = 1316722939, flag = 0, auto_col = -1, auto_val = 0, nrcols = 10, cols = 0xb616f310, colv = 0xb6175e70, nrrows = 58, rows = 0xb616e940, mt = 1316722962, next = 0x0, prev = 0x4c58586e}
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
On 9/23/11 1:57 PM, Bruno Bresciani wrote:
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
run these commands inside gdb.
Daniel
Best Regards
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello Daniel,
I'm still analyzing the source code of db_text module and I can't get find the reason of core when variable _tbc->prev is accessed. Did you obtain some conclusion about this core?
PS: In kamailio 1.5.0 I can't get replicate this core
Best Regards
2011/9/26 Bruno Bresciani bruno.bresciani@gmail.com
Hello,
Follows the output of *p *_tbc->prev*:
(gdb) p *_tbc->prev Cannot access memory at address 0x4c58586e
Best Regards
2011/9/24 Daniel-Constantin Mierla miconda@gmail.com
Hello,
thanks, the only possibility then is that the previous item in the list of tables has something wrong in it, send also the output for:
p *_tbc->prev
Actually, from now I see the _tmb->prev is 0x4c58586e and _tbc is 0xb6175d20, so the pointers are in different memory zones, it could be pkg one and shm the other. But lets see first the output of p *_tbc->prev
Cheers, Daniel
On 9/23/11 2:11 PM, Bruno Bresciani wrote:
Follows the output:
*p _tbc* $1 = (dbt_table_p) 0xb6175d20
*(gdb) p *_tbc* $312 = {dbname = {s = 0xb616d780 "/axs/cfg/db_text", len = 16}, name = {s = 0xb616e288 "subscriber", len = 10}, hash = 6, mark = 1316722939, flag = 0, auto_col = -1, auto_val = 0, nrcols = 10, cols = 0xb616f310, colv = 0xb6175e70, nrrows = 58, rows = 0xb616e940, mt = 1316722962, next = 0x0, prev = 0x4c58586e}
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
On 9/23/11 1:57 PM, Bruno Bresciani wrote:
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
run these commands inside gdb.
Daniel
Best Regards
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello ALL,
Someone knows why at line 149 in .../kamailio-3.1.2/modules_k/db_text/dbt_tb.c the shm_malloc function sometimes allocates memory to dtp->prev but sometimes doesn't? I'm asking this question because when the subscriber table is being loading to shared memory in db_text module, dtp->prev is allocated but on version, dispatcher, location table it doesn't... Analysing the source code I can't see any reason to this behavior.
The allocation of dtp->prev to subscriber table is generating a core at db_text module.
Best Regards
2011/9/27 Bruno Bresciani bruno.bresciani@gmail.com
Hello Daniel,
I'm still analyzing the source code of db_text module and I can't get find the reason of core when variable _tbc->prev is accessed. Did you obtain some conclusion about this core?
PS: In kamailio 1.5.0 I can't get replicate this core
Best Regards
2011/9/26 Bruno Bresciani bruno.bresciani@gmail.com
Hello,
Follows the output of *p *_tbc->prev*:
(gdb) p *_tbc->prev Cannot access memory at address 0x4c58586e
Best Regards
2011/9/24 Daniel-Constantin Mierla miconda@gmail.com
Hello,
thanks, the only possibility then is that the previous item in the list of tables has something wrong in it, send also the output for:
p *_tbc->prev
Actually, from now I see the _tmb->prev is 0x4c58586e and _tbc is 0xb6175d20, so the pointers are in different memory zones, it could be pkg one and shm the other. But lets see first the output of p *_tbc->prev
Cheers, Daniel
On 9/23/11 2:11 PM, Bruno Bresciani wrote:
Follows the output:
*p _tbc* $1 = (dbt_table_p) 0xb6175d20
*(gdb) p *_tbc* $312 = {dbname = {s = 0xb616d780 "/axs/cfg/db_text", len = 16}, name = {s = 0xb616e288 "subscriber", len = 10}, hash = 6, mark = 1316722939, flag = 0, auto_col = -1, auto_val = 0, nrcols = 10, cols = 0xb616f310, colv = 0xb6175e70, nrrows = 58, rows = 0xb616e940, mt = 1316722962, next = 0x0, prev = 0x4c58586e}
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
On 9/23/11 1:57 PM, Bruno Bresciani wrote:
Sorry... but I didn't understand how I get the output of:
p _tbc p *_tbc
run these commands inside gdb.
Daniel
Best Regards
2011/9/23 Daniel-Constantin Mierla miconda@gmail.com
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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
-
Bruno Bresciani -
Daniel-Constantin Mierla