Sorry... but I didn't understand how I get the output of: p _tbc p *_tbc
Best Regards 2011/9/23 Daniel-Constantin Mierla <mico...@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 <mico...@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-us...@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-us...@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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users