[SR-Users] The problem of get_aor_hash function
tyd
ydtzou at gmail.com
Fri Jul 20 07:23:24 CEST 2018
Hi, Danial
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.
(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\000\000\000\000\000\000`\255\205\234\001\000\000\000\230t\r\027\232\177\000\000`\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.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180720/c2b86713/attachment.html>
More information about the sr-users
mailing list