[SR-Users] The problem of get_aor_hash function
Henning Westerholt
hw at kamailio.org
Fri Jul 20 08:34:33 CEST 2018
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 at 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 <miconda at 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
More information about the sr-users
mailing list