Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I noticed at least one regression while testing out kamailio 5.6.0: the same configuration yields a different result after upgrading from 5.5.4. More specifically, this xlog line/statement:
xlog("L_CRIT", "vn is $vn(cli_164_src_noccgr), to int is $(vn(cli_164_src_noccgr){s.int})\n");
Prints the following in syslog for $vn(cli_164_src_noccgr) = "2152157200":
vn is 2152157200, to int is 2152157200vn is 2152157200, to int isI've only tested this with a couple of values and it doesn't always happen, for example for $vn(cli_164_src_noccgr) = "2103260000" the issue doesn't manifest.
Only thing I could think of is 2103260000 can be represented (unsigned) by 31 bits, whereas you need 32 bits for 2152157200? I skimmed over pv_trans.c and there weren't any obvious commits that could take the blame, at least not to me. Perhaps this is a compiler/glibc thing?
Try the transformation above with various values for the pseudovariable being transformed, I guess.
version: kamailio 5.6.0-rc1 (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_BLOCKLIST, 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 10.2.1
Linux sbcprov0-stage-lhe0-cn1 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.