Am Freitag, 20. Juli 2018, 07:23:24 CEST schrieb tyd: > I had modified ims_usrloc_pcscf/udomain.c about hash function and related > codes. > ex. via_host replaces with aor > > aorhash = get_aor_hash(_d, &contact_info->aor, contact_info->via_port, > contact_info->via_prot); > //aorhash = get_aor_hash(_d, &contact_info->via_host, > contact_info->via_port, contact_info->via_prot); > //aorhash = get_aor_hash(_d, &contact_info->via_host, > contact_info->via_port, contact_info->via_prot); > //aorhash = get_aor_hash(_d, &contact_info->via_host, > contact_info->via_port, contact_info->via_prot); > > When PCSCF DB is empty, it's OK. > But if there are data in PCSCF DB, the PCSCF process was crashed. > Below is the gdb content. > Could you help to find the problem? > Thanks.
Hello, I am also not that familiar with the IMS modules. If you did a modification t the code and now its crashes the best would be to discuss this on our developer list sr-dev. The respective module developers are also there and could assist as well. Best regards, Henning > (gdb) bt full > #0 0x00007f9a2c688fc3 in core_hash (s1=0x7f9a2c89e908 <ci.13657+8>, > s2=0x0, size=0) > at ../../hashes.h:276 > p = 0x0 > end = 0x0 > v = 389295844 > h = 0 > #1 0x00007f9a2c68ac01 in get_aor_hash (_d=0x7f9a173436e0, > via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) > at usrloc.c:147 > aorhash = 0 > __FUNCTION__ = "get_aor_hash" > #2 0x00007f9a2c68a8a9 in get_hash_slot (_d=0x7f9a173436e0, > via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) > at usrloc.c:137 > sl = 2000 > __FUNCTION__ = "get_hash_slot" > #3 0x00007f9a2c66e9f4 in lock_udomain (_d=0x7f9a173436e0, > via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) > at udomain.c:273 > sl = 0 > #4 0x00007f9a2c67994d in preload_udomain (_c=0x7f9a2e3162f8, > _d=0x7f9a173436e0) > at udomain.c:866 > ci = 0x7f9a2c89e900 <ci.13657> > row = 0x7f9a2e340210 > columns = {0x7f9a2c89e2b0 <domain_col>, 0x7f9a2c89e2c0 <aor_col>, > 0x7f9a2c89e2d0 <host_col>, 0x7f9a2c89e2e0 <port_col>, > 0x7f9a2c89e2f0 <protocol_col>, 0x7f9a2c89e300 <received_col>, > 0x7f9a2c89e310 <received_port_col>, 0x7f9a2c89e320 > <received_proto_col>, > 0x7f9a2c89e350 <rx_session_id_col>, 0x7f9a2c89e360 > <reg_state_col>, > 0x7f9a2c89e370 <expires_col>, 0x7f9a2c89e390 <socket_col>, > 0x7f9a2c89e380 <service_routes_col>, 0x7f9a2c89e3a0 > <public_ids_col>, > 0x7f9a2c89e330 <path_col>} > res = 0x7f9a2e33ff40 > aor = {s = 0xb83059 "sip:d4173c5dcbdd1529@172.28.20.225:5080 > ;transport=udp", > len = 53} > i = 0 > n = 0 > c = 0x7f9a2e335c20 > __FUNCTION__ = "preload_udomain" > #5 0x00007f9a2c68852d in child_init (_rank=1) at ul_mod.c:249 > ptr = 0x7f9a17342c70 > __FUNCTION__ = "child_init" > #6 0x00000000005308c6 in init_mod_child (m=0x7f9a2e2fbcf0, rank=1) at > sr_module.c:921 > __FUNCTION__ = "init_mod_child" > #7 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fbfa0, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #8 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fcc80, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #9 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd260, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #10 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd610, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #11 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fdc40, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #12 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe158, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #13 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe460, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #14 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fedc8, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #15 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ff418, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #16 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ffb48, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #17 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3000f0, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > ---Type <return> to continue, or q <return> to quit--- > #18 0x00000000005305e3 in init_mod_child (m=0x7f9a2e300510, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #19 0x00000000005305e3 in init_mod_child (m=0x7f9a2e301898, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #20 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302130, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #21 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3026d8, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #22 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302a50, rank=1) at > sr_module.c:918 > __FUNCTION__ = "init_mod_child" > #23 0x0000000000530bfe in init_child (rank=1) at sr_module.c:947 > No locals. > #24 0x0000000000485bd5 in fork_process (child_id=1, > desc=0x7ffe9c85acc0 "udp receiver child=0 sock=172.28.20.216:4060", > make_sock=1) > at pt.c:327 > pid = 0 > child_process_no = 1 > ret = -1 > new_seed1 = 570787820 > new_seed2 = 1356713246 > sockfd = {-1, -1} > __FUNCTION__ = "fork_process" > #25 0x000000000052024c in main_loop () at main.c:1586 > i = 0 > pid = 32766 > si = 0x7f9a2e2f1f10 > si_desc = "udp receiver child=0 sock=172.28.20.216:4060 > \000\177\000\000$[d\000\000\000\000\000\b\000\000\000\000\000\000\000(,4\027 > \232\177\000\000\000\360\f\027\232\177\000\000P,4\027\232\177\000\000`\000\0 > 00\000\000\000\000\000`\255\205\234\001\000\000\000\230t\r\027\232\177\000\0 > 00`\255\205\234\376\177\000\000H\036\064.\232\177\000" nrprocs = 8 > woneinit = 0 > __FUNCTION__ = "main_loop" > ---Type <return> to continue, or q <return> to quit--- > #26 0x0000000000527a79 in main (argc=7, argv=0x7ffe9c85b0d8) at main.c:2616 > cfg_stream = 0xad6010 > c = -1 > r = 0 > tmp = 0x7ffe9c85b818 "" > tmp_len = 0 > port = 0 > proto = 0 > options = 0x74b160 > ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:" > ret = -1 > seed = 2634858459 > rfd = 4 > debug_save = 0 > debug_flag = 0 > dont_fork_cnt = 0 > n_lst = 0x0 > p = 0x0 > st = {st_dev = 19, st_ino = 72092, st_nlink = 2, st_mode = 16832, > st_uid = 0, > st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = > 4096, > st_blocks = 0, st_atim = {tv_sec = 1532054497, tv_nsec = > 553300960}, > st_mtim = {tv_sec = 1532054692, tv_nsec = 531753344}, st_ctim = { > tv_sec = 1532054692, tv_nsec = 531753344}, __unused = {0, 0, 0}} > __FUNCTION__ = "main" > (gdb) > > 2018-07-16 15:54 GMT+08:00 Daniel-Constantin Mierla <mico...@gmail.com>: > > Hello, > > > > On 04.07.18 09:25, tyd wrote: > > > Dear all, > > > > > > I'm trying Kamailio 5.1.4 and IMS module. > > > When registering to Kamailio IMS using the same ip and port for 30 > > > users (different contact user part), the P-CSCF get the same hash > > > number and aor value. > > > > > > The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, > > > _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. > > > Because hashing with host, port, prot will get the same hash value. > > > > > > Anyone can help this ? > > > > I am not using the ims module, but the hash id is typically for speeding > > up the searching, there can be collisions also for different values, so > > I expect there is a matching rule on other attributes at some point, not > > only the hash id. -- If you like my work in the Kamailio project, it would be great if you could consider supporting me on Patreon: https://www.patreon.com/henningw _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users