Hello,<br><br>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...<br>
<br>Follows the output of 'bt full' from gdb:<br><br>Program terminated with signal 11, Segmentation fault.<br>#0 0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380, sync=0) at dbt_lib.c:238<br>238 dbt_lib.c: Arquivo ou diretório não encontrado.<br>
in dbt_lib.c<br>(gdb) bt full<br>#0 0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380, sync=0) at dbt_lib.c:238<br> _tbc = (dbt_table_p) 0xb6175d20<br> hash = 6<br>#1 0x008b3f38 in dbt_db_get_table (_dc=0xb60fde60, _s=0xbfc94380) at dbt_lib.c:300<br>
_tbc = (dbt_table_p) 0xb6175d20<br> hash = 6<br>#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<br> _tbc = <value optimized out><br>
_drp = <value optimized out><br> _dres = <value optimized out><br> lkey = <value optimized out><br> lres = (int *) 0x0<br> _o_k = (db_key_t *) 0x0<br> _o_op = 0x0<br>
_o_n = <value optimized out><br> _o_l = <value optimized out><br> _o_nc = <value optimized out><br>#3 0x001ae088 in digest_authenticate (msg=0x82df8f8, realm=<value optimized out>, tname=<value optimized out>, hftype=HDR_AUTHORIZATION_T) at authorize.c:98<br>
cred = <value optimized out><br> keys = {0x1b14c8, 0x1b14d0}<br> vals = {{type = DB1_STR, nul = 0, free = 165777064, val = {int_val = 136948130, ll_val = 17316817314, double_val = 8.5556445301562903e-314,<br>
time_val = 136948130,<br> 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 = {<br>
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 = {<br>
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,<br>
val = {int_val = 137215560, ll_val = 64561725000, double_val = 3.1897730358749953e-313, time_val = 137215560, string_val = 0x82dbe48 "192.168.166.199",<br> str_val = {s = 0x82dbe48 "192.168.166.199", len = 15}, blob_val = {s = 0x82dbe48 "192.168.166.199", len = 15}, bitmap_val = 137215560}}}<br>
result = {s = 0x0, len = 0}<br> n = <value optimized out><br> 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¶"...<br>
h = (struct hdr_field *) 0x82e0398<br> domain = {s = 0x82dbe48 "192.168.166.199", len = 15}<br> table = {s = 0x82d8f60 "subscriber", len = 10}<br> result = (db1_res_t *) 0x0<br>
ret = 0<br><br><br>Best Regards<br><br><div class="gmail_quote">2011/9/23 Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
can you send the output of 'bt full' from gdb?<br>
<br>
How often the subscriber table is changed? I see in this case the
deletion of the table is done without a lock.<br>
<br>
Cheers,<br>
Daniel<div><div></div><div class="h5"><br>
<br>
On 9/22/11 9:44 PM, Bruno Bresciani wrote:
</div></div><blockquote type="cite"><div><div></div><div class="h5">Hi All,<br>
<br>
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...<br>
<br>
Someone Can Help me to understand why this core is happening?
Below is part of kamailio's trace and gdb core too.<br>
<br>
<br>
Kamailio's trace:<br>
<br>
<b>Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2327]: DEBUG: auth_db
[authorize.c:239]: realm value [192.168.166.199]</b><br>
Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2327]: DEBUG: auth [api.c:95]:
auth: digest-algo: MD5 parsed value: 1<br>
<b>Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2327]: DEBUG: db_text
[dbt_file.c:78]: [subscriber] was updated</b><br>
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<br>
Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2324]: ALERT: <core>
[main.c:744]: core was generated<br>
Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2324]: INFO: <core>
[main.c:756]: INFO: terminating due to SIGCHLD<br>
Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2335]: INFO: <core>
[main.c:807]: INFO: signal 15 received c<br>
Sep 22 16:35:54 sswpst00
/home2/local/kamailio/sbin/kamailio[2335]: DEBUG: <core>
[main.c:818]: Memory status (pkg):<br>
<br>
gdb core trace:<br>
<br>
Core was generated by `/home2/local/kamailio/sbin/kamailio -P
/var/run/kamailio.pid'.<br>
Program terminated with signal 11, Segmentation fault.<br>
<b>#0 0x00f21603 in dbt_db_del_table (_dc=0xb6071e60,
_s=0xbf837040, sync=0) at dbt_lib.c:238</b><br>
238 dbt_lib.c: Arquivo ou diretório não encontrado.<br>
in dbt_lib.c<br>
<br>
<br>
Best Regards<br>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote><font color="#888888">
<br>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Oct 10-13, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a></pre>
</font></div>
</blockquote></div><br>