[SR-Users] Core db_text module
Bruno Bresciani
bruno.bresciani at gmail.com
Fri Sep 30 16:47:28 CEST 2011
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 at 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 at 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 at 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 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>
>>>>
>>>>> Hello,
>>>>>
>>>>> interesting ... give also the output of:
>>>>>
>>>>> p _tbc
>>>>> p *_tbc
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 9/23/11 1:27 PM, Bruno Bresciani wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Doesn't exist a exact often that the table subscriber is changed, it
>>>>> can be changed at any time and almost always the core is generated. I was
>>>>> thinking the same thing that you, the deletion of the table is done without
>>>>> a lock, but the function dbt_db_get_table that call dbt_db_del_table does
>>>>> this lock previously...
>>>>>
>>>>> Follows the output of 'bt full' from gdb:
>>>>>
>>>>> Program terminated with signal 11, Segmentation fault.
>>>>> #0 0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380,
>>>>> sync=0) at dbt_lib.c:238
>>>>> 238 dbt_lib.c: Arquivo ou diretório não encontrado.
>>>>> in dbt_lib.c
>>>>> (gdb) bt full
>>>>> #0 0x008b3603 in dbt_db_del_table (_dc=0xb60fde60, _s=0xbfc94380,
>>>>> sync=0) at dbt_lib.c:238
>>>>> _tbc = (dbt_table_p) 0xb6175d20
>>>>> hash = 6
>>>>> #1 0x008b3f38 in dbt_db_get_table (_dc=0xb60fde60, _s=0xbfc94380) at
>>>>> dbt_lib.c:300
>>>>> _tbc = (dbt_table_p) 0xb6175d20
>>>>> hash = 6
>>>>> #2 0x008ae12b in dbt_query (_h=0x82e3c90, _k=0xbfc94378, _op=0x0,
>>>>> _v=0xbfc94348, _c=0x82e3e50, _n=1, _nc=2, _o=0x0, _r=0xbfc94390) at
>>>>> dbt_base.c:200
>>>>> _tbc = <value optimized out>
>>>>> _drp = <value optimized out>
>>>>> _dres = <value optimized out>
>>>>> lkey = <value optimized out>
>>>>> lres = (int *) 0x0
>>>>> _o_k = (db_key_t *) 0x0
>>>>> _o_op = 0x0
>>>>> _o_n = <value optimized out>
>>>>> _o_l = <value optimized out>
>>>>> _o_nc = <value optimized out>
>>>>> #3 0x001ae088 in digest_authenticate (msg=0x82df8f8, realm=<value
>>>>> optimized out>, tname=<value optimized out>, hftype=HDR_AUTHORIZATION_T) at
>>>>> authorize.c:98
>>>>> cred = <value optimized out>
>>>>> keys = {0x1b14c8, 0x1b14d0}
>>>>> vals = {{type = DB1_STR, nul = 0, free = 165777064, val =
>>>>> {int_val = 136948130, ll_val = 17316817314, double_val =
>>>>> 8.5556445301562903e-314,
>>>>> time_val = 136948130,
>>>>> string_val = 0x829a9a2 "3022\", realm=\"192.168.166.199\",
>>>>> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\",
>>>>> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, uri=\
>>>>> "sip:192.168.166.199\",
>>>>> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., str_val = {
>>>>> s = 0x829a9a2 "3022\", realm=\"192.168.166.199\",
>>>>> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\",
>>>>> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, uri=\
>>>>> "sip:192.168.166.199\",
>>>>> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., len = 4}, blob_val = {
>>>>> s = 0x829a9a2 "3022\", realm=\"192.168.166.199\",
>>>>> nonce=\"TnuaJ057mPskvCOYDgyAURuuottiYy7cIAQKLUA=\",
>>>>> cnonce=\"4VwQFl/7Ei+IWecbrZ9rug\", algorithm=MD5, uri=\
>>>>> "sip:192.168.166.199\",
>>>>> response=\"45b23bc0e48592fb57b1ebc87f0e3dbc\""..., len = 4}, bitmap_val =
>>>>> 136948130}}, {type = DB1_STR, nul = 0, free = 8200,
>>>>> val = {int_val = 137215560, ll_val = 64561725000, double_val =
>>>>> 3.1897730358749953e-313, time_val = 137215560, string_val = 0x82dbe48
>>>>> "192.168.166.199",
>>>>> str_val = {s = 0x82dbe48 "192.168.166.199", len = 15}, blob_val =
>>>>> {s = 0x82dbe48 "192.168.166.199", len = 15}, bitmap_val = 137215560}}}
>>>>> result = {s = 0x0, len = 0}
>>>>> n = <value optimized out>
>>>>> ha1 =
>>>>> "\000\000\000\000\220GÉ¿\000\000\000\000ï=\000\000ÒBÉ¿L\215á\t\000\000\000\000(Óà\tÔBÉ¿F\000\000\000yv¯\000L\215á\t",
>>>>> '\0' <repeats 12 times>,
>>>>> "ÿÿÿÿ\a\000\000\000a{¯\000^{¯\000\000\000\000\000\000\000\000\000ÿÿÿÿ+\000\000\000\000\000\000\000\001\000\000\0008DÉ¿\210\033-\bÈVÉ¿HDÉ¿&\205\017\bÈVÉ¿øø-\b8DÉ¿P\020-\b",
>>>>> '\0' <repeats 32 times>, "
>>>>> e¯\000TDÉ¿`ñ\000\000ÐÑ\000\000\\\222¯d\030\000\000\000\000\000\000\000»¬£\000;\216á\t
>>>>> 1±\000\000 \000\000ÔCÉ¿8\216á\t\bÔ\r¶"...
>>>>> h = (struct hdr_field *) 0x82e0398
>>>>> domain = {s = 0x82dbe48 "192.168.166.199", len = 15}
>>>>> table = {s = 0x82d8f60 "subscriber", len = 10}
>>>>> result = (db1_res_t *) 0x0
>>>>> ret = 0
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>> 2011/9/23 Daniel-Constantin Mierla <miconda at gmail.com>
>>>>>
>>>>>> 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 at 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 at 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 at 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 at 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110930/649689c2/attachment-0001.htm>
More information about the sr-users
mailing list