[SR-Users] Core db_text module
Daniel-Constantin Mierla
miconda at gmail.com
Sat Sep 24 09:19:00 CEST 2011
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 at gmail.com
> <mailto:miconda at 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 at gmail.com
>> <mailto:miconda at 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 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 <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 <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/20110924/53c28b09/attachment-0001.htm>
More information about the sr-users
mailing list