Re: [SR-Users] The problem of get_aor_hash function
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, _info->aor, contact_info->via_port,
> contact_info->via_prot);
> //aorhash = get_aor_hash(_d, _info->via_host,
> contact_info->via_port, contact_info->via_prot);
> //aorhash = get_aor_hash(_d, _info->via_host,
> contact_info->via_port, contact_info->via_prot);
> //aorhash = get_aor_hash(_d, _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 0x7f9a2c688fc3 in core_hash (s1=0x7f9a2c89e908 ,
> s2=0x0, size=0)
> at ../../hashes.h:276
> p = 0x0
> end = 0x0
> v = 389295844
> h = 0
> #1 0x7f9a2c68ac01 in get_aor_hash (_d=0x7f9a173436e0,
> via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
> at usrloc.c:147
> aorhash = 0
> __FUNCTION__ = "get_aor_hash"
> #2 0x7f9a2c68a8a9 in get_hash_slot (_d=0x7f9a173436e0,
> via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
> at usrloc.c:137
> sl = 2000
> __FUNCTION__ = "get_hash_slot"
> #3 0x7f9a2c66e9f4 in lock_udomain (_d=0x7f9a173436e0,
> via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
> at udomain.c:273
> sl = 0
> #4 0x7f9a2c67994d in preload_udomain (_c=0x7f9a2e3162f8,
> _d=0x7f9a173436e0)
> at udomain.c:866
> ci = 0x7f9a2c89e900
> row = 0x7f9a2e340210
> columns = {0x7f9a2c89e2b0 , 0x7f9a2c89e2c0 ,
> 0x7f9a2c89e2d0 , 0x7f9a2c89e2e0 ,
> 0x7f9a2c89e2f0 , 0x7f9a2c89e300 ,
> 0x7f9a2c89e310 , 0x7f9a2c89e320
> ,
> 0x7f9a2c89e350 , 0x7f9a2c89e360
> ,
> 0x7f9a2c89e370 , 0x7f9a2c89e390 ,
> 0x7f9a2c89e380 , 0x7f9a2c89e3a0
> ,
> 0x7f9a2c89e330 }
> 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 0x7f9a2c68852d in child_init (_rank=1) at ul_mod.c:249
> ptr = 0x7f9a17342c70
> __FUNCTION__ = "child_init"
> #6 0x005308c6 in init_mod_child (m=0x7f9a2e2fbcf0, rank=1) at
> sr_module.c:921
> __FUNCTION__ = "init_mod_child"
> #7 0x005305e3 in init_mod_child (m=0x7f9a2e2fbfa0, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #8 0x005305e3 in init_mod_child (m=0x7f9a2e2fcc80, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #9 0x005305e3 in init_mod_child (m=0x7f9a2e2fd260, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #10 0x005305e3 in init_mod_child (m=0x7f9a2e2fd610, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #11 0x005305e3 in init_mod_child (m=0x7f9a2e2fdc40, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #12 0x005305e3 in init_mod_child (m=0x7f9a2e2fe158, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #13 0x005305e3 in init_mod_child (m=0x7f9a2e2fe460, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #14 0x005305e3 in init_mod_child (m=0x7f9a2e2fedc8, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #15 0x005305e3 in init_mod_child (m=0x7f9a2e2ff418, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #16 0x005305e3 in init_mod_child (m=0x7f9a2e2ffb48, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #17 0x005305e3 in init_mod_child (m=0x7f9a2e3000f0, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> ---Type to continue, or q to quit---
> #18 0x005305e3 in init_mod_child (m=0x7f9a2e300510, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #19 0x005305e3 in init_mod_child (m=0x7f9a2e301898, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #20 0x005305e3 in init_mod_child (m=0x7f9a2e302130, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #21 0x005305e3 in init_mod_child (m=0x7f9a2e3026d8, rank=1) at
> sr_module.c:918
> __FUNCTION__ = "init_mod_child"
> #22 0x005305e3 in init_mod_child (m=0x7f9a2e302a50, rank=1) at
>
Re: [SR-Users] The problem of get_aor_hash function
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, _info->aor, contact_info->via_port,
contact_info->via_prot);
//aorhash = get_aor_hash(_d, _info->via_host,
contact_info->via_port, contact_info->via_prot);
//aorhash = get_aor_hash(_d, _info->via_host,
contact_info->via_port, contact_info->via_prot);
//aorhash = get_aor_hash(_d, _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 0x7f9a2c688fc3 in core_hash (s1=0x7f9a2c89e908 ,
s2=0x0, size=0)
at ../../hashes.h:276
p = 0x0
end = 0x0
v = 389295844
h = 0
#1 0x7f9a2c68ac01 in get_aor_hash (_d=0x7f9a173436e0,
via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
at usrloc.c:147
aorhash = 0
__FUNCTION__ = "get_aor_hash"
#2 0x7f9a2c68a8a9 in get_hash_slot (_d=0x7f9a173436e0,
via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
at usrloc.c:137
sl = 2000
__FUNCTION__ = "get_hash_slot"
#3 0x7f9a2c66e9f4 in lock_udomain (_d=0x7f9a173436e0,
via_host=0x7f9a2c89e908 , via_port=5080, via_proto=53877)
at udomain.c:273
sl = 0
#4 0x7f9a2c67994d in preload_udomain (_c=0x7f9a2e3162f8,
_d=0x7f9a173436e0)
at udomain.c:866
ci = 0x7f9a2c89e900
row = 0x7f9a2e340210
columns = {0x7f9a2c89e2b0 , 0x7f9a2c89e2c0 ,
0x7f9a2c89e2d0 , 0x7f9a2c89e2e0 ,
0x7f9a2c89e2f0 , 0x7f9a2c89e300 ,
0x7f9a2c89e310 , 0x7f9a2c89e320
,
0x7f9a2c89e350 , 0x7f9a2c89e360
,
0x7f9a2c89e370 , 0x7f9a2c89e390 ,
0x7f9a2c89e380 , 0x7f9a2c89e3a0
,
0x7f9a2c89e330 }
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 0x7f9a2c68852d in child_init (_rank=1) at ul_mod.c:249
ptr = 0x7f9a17342c70
__FUNCTION__ = "child_init"
#6 0x005308c6 in init_mod_child (m=0x7f9a2e2fbcf0, rank=1) at
sr_module.c:921
__FUNCTION__ = "init_mod_child"
#7 0x005305e3 in init_mod_child (m=0x7f9a2e2fbfa0, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#8 0x005305e3 in init_mod_child (m=0x7f9a2e2fcc80, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#9 0x005305e3 in init_mod_child (m=0x7f9a2e2fd260, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#10 0x005305e3 in init_mod_child (m=0x7f9a2e2fd610, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#11 0x005305e3 in init_mod_child (m=0x7f9a2e2fdc40, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#12 0x005305e3 in init_mod_child (m=0x7f9a2e2fe158, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#13 0x005305e3 in init_mod_child (m=0x7f9a2e2fe460, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#14 0x005305e3 in init_mod_child (m=0x7f9a2e2fedc8, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#15 0x005305e3 in init_mod_child (m=0x7f9a2e2ff418, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#16 0x005305e3 in init_mod_child (m=0x7f9a2e2ffb48, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#17 0x005305e3 in init_mod_child (m=0x7f9a2e3000f0, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
---Type to continue, or q to quit---
#18 0x005305e3 in init_mod_child (m=0x7f9a2e300510, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#19 0x005305e3 in init_mod_child (m=0x7f9a2e301898, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#20 0x005305e3 in init_mod_child (m=0x7f9a2e302130, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#21 0x005305e3 in init_mod_child (m=0x7f9a2e3026d8, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#22 0x005305e3 in init_mod_child (m=0x7f9a2e302a50, rank=1) at
sr_module.c:918
__FUNCTION__ = "init_mod_child"
#23 0x00530bfe in init_child (rank=1) at sr_module.c:947
No locals.
#24 0x00485bd5 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 0x0052024c in main_loop () at main.c:1586
i = 0
pid = 32766
si
Re: [SR-Users] The problem of get_aor_hash function
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 ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
