### Description
Currently, the `geoip2` module loads the IP database at startup and keeps it in cache and there is no way to tell Kamailio to reload the database without a full restart.
### Possible Solutions
To keep this module inline with other modules that use external datasources, I would suggest to implement a new RPC command and a new geoip2 function to reload the database defined in the `path` geoip2 modparam without the need of a restart.
I'm not aware of the effort required for implementing either of them, but only having an RPC command would effectively solve this issue as you can call RPC commands from within Kamailio conf, thus, the reload function would not be something strictly required but more of a nice-to-have.
### Examples:
Function:
```
geoip2_reload()
```
RPC command:
```
kamctl rpc gip2.reload / kamctl rpc geoip2.reload
```
Kamcmd command:
```
kamcmd geoip2.reload
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2029
### Description
The Kamailio 5.4.x dialog profiles functionality can lead to dead-lock on certain high-load scenarios.
The Kamailio dialog profiles are used to track parallel channels for about 200 outgoing PSTN carrier interconnections. During high traffic times (like several thousands parallel calls) the Kamailio server will frequently (e.g. hourly) goes into an end-less loop while executing get_profile_size in the configuration script. This causes the locking for the dialog profiles never be released and Kamailio will stop serving traffic. Internal monitoring tools and RPC commands stay working, as long as they do not touch the dialog functionality.
A similar (dedicated) Kamailio setup is used for tracking parallel channels for customers. Here the dead-lock is not observed that frequently, but aparentely also some crashes happens in a much longer time interval.
### Troubleshooting
After analysis of the back-traces with GDB the get_profile_size() function was removed from the configuration script. After this change the crash did not happened anymore for several days.
#### Reproduction
Issue could not be reproduced so far.
#### Debugging Data
##### bt 1 (some data removed)
(gdb) bt
\# 0 0x00007f57cf3b00da in get_profile_size (profile=0x7f50ccbc7e80, value=0x7ffd9928f300) at dlg_profile.c:859
n = 364
i = 12
ph = 0x7f50d3e4b7d0
\# 1 0x00007f57cf419c67 in w_get_profile_size_helper (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7ffd9928f300, spd=0x7f57d6916960) at dialog.c:941
\# 2 0x00007f57cf41a459 in w_get_profile_size3 (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7f57d6935118, result=0x7f57d6916960) at dialog.c:982
\# 3 0x0000000000463fea in do_action (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1094
\# 4 0x00000000004711ee in run_actions (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1581
\# 5 0x000000000046058b in do_action (h=0x7ffd99293610, a=0x7f57d690fda8, msg=0x7f57d699d418) at core/action.c:700
The first back-trace was taking from a running process with gdb. The counter in f0 does not increased that much during this time, probably due the overflow of the loop counter.
##### bt2 (analysis with data structure with gdb scripts)
Here the loop counter in f0 showed a really high value. Expected size of dialog profiles hash table:
(gdb) p profile->entries[3]
$4 = {first = 0x7f9bfd4aad98, content = 2068}
(gdb) p profile->entries[7]
$3 = {first = 0x7f9c12079f70, content = 784}
(gdb) p profile->entries[12]
$6 = {first = 0x7f9c02be5d50, content = 7600}
(gdb) p profile->entries[14]
$2 = {first = 0x7f9bff636de8, content = 6764}
hash table bucket 14 shows a lot of corruption and the loop never ends (carrier names and IPs replaced). The list for hash bucket 7 got linked to the list for hash bucket 14:
counter 6755: prev 0x7f9c0b9dcde0 - current 0x7f9c02e5b378 - next 0x7f9c0a5f9ba0 - value carrier1-XX.XX - hash 14
counter 6756: prev 0x7f9c02e5b378 - current 0x7f9c0a5f9ba0 - next 0x7f9c0860b968 - value carrier1-XX.XX▒▒▒▒ - hash 14
counter 6757: prev 0x7f9c0a5f9ba0 - current 0x7f9c0860b968 - next 0x7f9bfe3f3a78 - value carrier1-XX.XX▒▒▒▒ - hash 14
counter 6758: prev 0x7f9c0860b968 - current 0x7f9bfe3f3a78 - next 0x7f9c10d977f0 - value carrier1-XX.XX - hash 14
counter 6759: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7
counter 6760: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7
counter 6761: prev 0x7f9c0ae198b0 - current 0x7f9c12079f70 - next 0x7f9c011f2540 - value-carrier2-XX.XX▒▒▒▒ - hash 7
counter 6762: prev 0x7f9c12079f70 - current 0x7f9c011f2540 - next 0x7f9bfff886f0 - value carrier2-XX.XX▒▒▒▒ - hash 7
counter 6763: prev 0x7f9c011f2540 - current 0x7f9bfff886f0 - next 0x7f9c05db00a8 - value carrier3-XX.XX= - hash 7
[...]
counter 28270: prev 0x7f9c019d06e8 - current 0x7f9bfaf18290 - next 0x7f9c12c90680 - value carrier2-XX.XX▒▒▒▒ - hash 7
counter 28271: prev 0x7f9bfaf18290 - current 0x7f9c12c90680 - next 0x7f9c086a2b58 - value-carrier2-XX.XX▒▒▒▒ - hash 7
counter 28272: prev 0x7f9c12c90680 - current 0x7f9c086a2b58 - next 0x7f9c0b4f09e8 - value carrier2-XX.XX▒▒▒▒ - hash 7
[...]
hash table bucket 7 is still consistent regarding the loop, but already shows initial sign of corruption. There is one item of the list for hash bucket 14 visible:
counter 780: prev 0x7f9c0db57ac8 - current 0x7f9c02225700 - next 0x7f9bfbf7db08 - value carrier2-XX.XX▒▒▒▒ - hash 7
counter 781: prev 0x7f9c02225700 - current 0x7f9bfbf7db08 - next 0x7f9c10d977f0 - value carrier1-XX.XX- hash 14
counter 782: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7
counter 783: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7
total size of hash table is 784
#### Log Messages
No special log messages observed.
#### SIP Traffic
SIP traffic looked ok during analysis of the core dumps.
### Possible Solutions
* adding additional safe-guards for the get_profile_size function to not access data from other hash buckets
* stopping the loop counter after some threshold
* finding and fixing the source of the internal data corruption (obviously)
* refactoring the dialog modules to use another approach for storing the dialog profile information
### Additional Information
* **Kamailio version**:
Kamailio 5.4.7, compiled from git repository
* **Operating System**:
CentOS 7.9
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2923
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
```
apt install kamailio kamailio-*
find /usr/lib/x86_64-linux-gnu/kamailio/modules -name jwt.so
and nothing.
```
<!--
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio5.5.2
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
debian10
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2883
### Description
At the moment db_redis driver does not support interfacing with a redis cluster. This is a proposal to add support to it.
The db_redis module will get a new module parameter to enable cluster support (with default 0 - disabled):
```
modparam("db_redis", "cluster", 1)
```
The redis url used by other modules needs to specify all nodes in the cluster, and must NOT include redis database number (since it's not supported in cluster mode):
```
#!define DBURL_USRLOC "redis://10.0.1.1:6379,10.0.1.2:6379,10.0.1.3:6379"
```
The implementation is going to use the [hiredis-cluster](https://github.com/Nordix/hiredis-cluster) library (BSD license). If cluster mode is not enabled the module will behave like before, i.e. all calls to redis will use hiredis library directly.
If you find this proposal sensible, I'll start coding it.
Feedback is welcome, of course!
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2977
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/2977(a)github.com>
#### Pre-Submission Checklist
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
EPEL now includes a openssl11 package for CentOS 7. This feature is for users who want to build kamailio-tls with OpenSSL 1.1.1 instead of OpenSSL 1.0.2.
It is implemented as a `--with=openssl11` conditional (the default os off), so should not affect/change the regular CentOS 7 builds as distributed by kamailio.org.
This is for adventurous users on CentOS 7 willing to maintain their own OpenSSL 1.1.1-enabled TLS package. EPEL dependencies( openssl11-libs, openssl11-devel) are required at runtime and for build.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2779
-- Commit Summary --
* pkg: enable CentOS 7 to build with OpenSSL 1.1.1
-- File Changes --
M pkg/kamailio/obs/kamailio.spec (32)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2779.patchhttps://github.com/kamailio/kamailio/pull/2779.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2779
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
I am uac module with database. uacreg table have the send_socket column. i do have 2 kamailio server running. i want only kamailio-1 should send register to uacreg entries. for this i have used send_socket column with socket of kamailio-1. After this we can see both kamailio server sending registration and that's the problem.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
loadmodule "uac.so"
modparam("uac","auth_username_avp","$avp(auser)")
modparam("uac","auth_password_avp","$avp(apass)")
modparam("uac","auth_realm_avp","$avp(arealm)")
modparam("uac", "reg_contact_addr", "EXTERNAL_IP:5060")
modparam("uac", "reg_db_url", DBURL)
and use send_socket into uacreg with kamailio-1 socket.
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.3.8 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 8.3.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
root@ip-10-0-12-135:/etc/kamailio# uname -a
Linux ip-10-0-12-135 5.3.0-1019-aws #21~18.04.1-Ubuntu SMP Mon May 11 12:33:03 UTC 2020 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2624
```
which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
CC (gcc) [M app_lua.so] app_lua_api.o
app_lua_api.c: In function 'lua_sr_kemi_register_libs':
app_lua_api.c:1942:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplicit-f
unction-declaration]
1942 | luaL_openlib(L, "KSR", _sr_crt_KSRMethods, 0);
| ^~~~~~~~~~~~
| luaL_openlibs
CC (gcc) [M app_lua.so] app_lua_kemi_export.o
CC (gcc) [M app_lua.so] app_lua_mod.o
LD (gcc) [M app_lua.so] app_lua.so
which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
CC (gcc) [M app_lua_sr.so] app_lua_sr_api.o
app_lua_sr_api.c: In function 'lua_sr_core_openlibs':
app_lua_sr_api.c:1614:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici
t-function-declaration]
1614 | luaL_openlib(L, "sr", _sr_core_Map, 0);
| ^~~~~~~~~~~~
| luaL_openlibs
CC (gcc) [M app_lua_sr.so] app_lua_sr_exp.o
app_lua_sr_exp.c: In function 'lua_sr_exp_openlibs':
app_lua_sr_exp.c:3686:3: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici
t-function-declaration]
3686 | luaL_openlib(L, "sr.sl", _sr_sl_Map, 0);
| ^~~~~~~~~~~~
| luaL_openlibs
CC (gcc) [M app_lua_sr.so] app_lua_sr_mod.o
LD (gcc) [M app_lua_sr.so] app_lua_sr.so
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2728
### Description
SQL queries that do not return a result set (such as INSERT, DELETE, UPDATE) always report errors when using db_unixodbc. The query succeeds, but the log indicates a failure.
#### Reproduction
Use db_unixodbc.so for sql queries.
Issue a valid query such as INSERT that is not expected to return a result set.
#### Log Messages
ERROR: db_unixodbc [res.c:52]: db_unixodbc_get_columns(): no columns returned from the query
ERROR: db_unixodbc [res.c:253]: db_unixodbc_convert_result(): getting column names failed
ERROR: db_unixodbc [dbase.c:271]: db_unixodbc_store_result(): failed to convert result
ERROR: <core> [db_query.c:197]: db_do_raw_query(): error while storing result
ERROR: sqlops [sql_api.c:297]: sql_do_query(): cannot do the query [DELETE FROM mytable WHERE id = 1]
### Additional Information
Kamailio Version 5.5.0
This issue was also reported to SR-users, but that user did not open an issue. (See https://lists.kamailio.org/pipermail/sr-users/2018-March/100581.html)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2810
### Description
<!--
Kamailoi crashes every 10 hours
-->
### Troubleshooting
coredump data below.
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(gdb) bt full
#0 0x000000000046ccdd in get_hash1_raw (s=0x5da51296 <Address 0x5da51296 out of bounds>, len=9) at core/hashes.h:109
p = 0x5da51296 <Address 0x5da51296 out of bounds>
v = 4100353960
h = 0
#1 0x000000000046cfb6 in str_hash_get (ht=0xa6d6c0 <cnts_hash_table>, key=0x5da51296 <Address 0x5da51296 out of bounds>, len=9) at core/str_hash.h:94
h = 0
e = 0x19
#2 0x000000000046debe in cnt_hash_lookup (group=0x7ffc2db9d7c0, name=0x7eff79693b80) at core/counters.c:420
e = 0x7eff80c48c88
first = 0xbd8191bc2e950d55
cnt_rec = 0x7eff80c48cb0
#3 0x000000000046e752 in counter_lookup_str (handle=0x7ffc2db9d7d0, group=0x7ffc2db9d7c0, name=0x7eff79693b80) at core/counters.c:541
cnt_rec = 0x19
#4 0x00007eff7d65b447 in get_stat (name=0x7eff79693b80) at ../../core/counters.h:197
h = {id = 13}
grp = {s = 0x0, len = 0}
#5 0x00007eff7d65c113 in statsc_svalue (name=0x7eff79693b80, res=0x7eff79693f4b) at statsc_mod.c:149
stat = 0xd
__FUNCTION__ = "statsc_svalue"
#6 0x00007eff7d65db79 in statsc_timer (ticks=113205942, param=0x0) at statsc_mod.c:274
sm = 0x7eff79693b70
tn = 1571099286
n = 115
__FUNCTION__ = "statsc_timer"
#7 0x00000000005db7f9 in sr_wtimer_exec (ticks=113205942, param=0x0) at core/timer_proc.c:390
wt = 0x7eff80c56f48
wn = 0x0
wp = 0x0
cs = 0
__FUNCTION__ = "sr_wtimer_exec"
#8 0x00000000005daa29 in fork_sync_timer (child_id=-1, desc=0x7c8a71 "secondary timer", make_sock=1, f=0x5db4f2 <sr_wtimer_exec>, param=0x0, interval=1000) at core/timer_proc.c:224
pid = 0
ts1 = 1811295077
ts2 = 1000
#9 0x00000000005dbb26 in sr_wtimer_start () at core/timer_proc.c:416
__FUNCTION__ = "sr_wtimer_start"
#10 0x0000000000425a33 in main_loop () at main.c:1729
i = 8
pid = 3615
si = 0x0
si_desc = "udp receiver child=7 sock=91.216.86.57:5060\000\377~\000\000@۹-\374\177\000\000\020\207A\000\000\000\000\000\020\336\271-\374\177\000\000\323c{\000\000\000\000\000\031\000\000\000\000\000\000\000\000\000\000\004\000\000\000\000\000\000\200\000\000\000\000\000__:\201\377~\000\000\250\346\260v\377~\000\000\270\314À\377~\000"
nrprocs = 8
woneinit = 1
__FUNCTION__ = "main_loop"
#11 0x000000000042c72a in main (argc=7, argv=0x7ffc2db9def8) at main.c:2696
cfg_stream = 0x1ee3010
c = -1
r = 0
tmp = 0x7ffc2db9ef2c ""
tmp_len = 0
port = 0
proto = 0
options = 0x76a9a0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
---Type <return> to continue, or q <return> to quit--- info locals
seed = 2620966285
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x2
p = 0x0
st = {st_dev = 20, st_ino = 22346, 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 = 1568107728, tv_nsec = 458000000}, st_mtim = {
tv_sec = 1571064422, tv_nsec = 57000000}, st_ctim = {tv_sec = 1571064422, tv_nsec = 57000000}, __unused = {0, 0, 0}}
__FUNCTION__ = "main"
(gdb) list
104 register unsigned v;
105 register unsigned h;
106
107 h=0;
108
109 hash_update_str(s, s+len, p, v, h);
110 return hash_finish(h);
111 }
112
113
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
no relevant messages
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
seems to be triggered by internal timer
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.2.4 (x86_64/linux) 759867
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 759867
compiled on 12:20:22 Sep 11 2019 with gcc 4.8.5
```
* **Operating System**:
<!--
CentOS Linux release 7.4.1708 (Core)
Linux xxx 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
-->
```
CentOS Linux release 7.4.1708 (Core)
Linux xxx 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2101