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.bresci...@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.bresci...@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 <mico...@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 <mico...@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 <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 >>>> 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