Thanks for the report. To make it clear and easier to reproduce: the issue happens on the same environment (operating system, virtual machine etc..), the only difference are the kamailio versions? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3116#issuecomment-1131249075 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3116/1131249075(a)github.com>

To answer @henningw's question, yes. The steps were: * Produce the error on a (nearly clean) debian bullseye installation with kamailio 5.6.0 * On the same machine, change back to 5.5 repo and execute: `apt-get install kamailio=5.5.4+bpo11 kamailio-dbg=5.5.4+bpo11 kamailio-extra-modules=5.5.4+bpo11 kamailio-geoip2-modules=5.5.4+bpo11 kamailio-json-modules=5.5.4+bpo11 kamailio-mysql-modules=5.5.4+bpo11 kamailio-outbound-modules=5.5.4+bpo11 kamailio-phonenum-modules=5.5.4+bpo11 kamailio-presence-modules=5.5.4+bpo11 kamailio-python-modules=5.5.4+bpo11 kamailio-python3-modules=5.5.4+bpo11 kamailio-redis-modules=5.5.4+bpo11 kamailio-sctp-modules=5.5.4+bpo11 kamailio-snmpstats-modules=5.5.4+bpo11 kamailio-tls-modules=5.5.4+bpo11 kamailio-xml-modules=5.5.4+bpo11` * Run the test again (now the error doesn't appear) The output of `kamailio -v` after the downgrade is: ``` version: kamailio 5.5.4 (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 ``` @miconda Actually the second conversion (to string by xlog) only took place during my debugging. Originally I stumbled upon this because the mysql module would report failures after upgrading to 5.6. The actual use case was: ``` sql_pvquery("ca", "select lrn from telephony_lrn where number_from = $(vn(cli_164_src_noccgr){s.int})", "$vn(src_portnet)"); ``` This produces invalid SQL on 5.6.0~rc1, because the resulting query is: `select lrn from telephony_lrn where number_from = ;` I make the conversion here because `telephony_lrn`.`number_from` is of type INT, but I'm not sure if it's needed or if the sqlops module handles pv data types any differently, this particular statement was written several years ago and I don't remember if the transformation is required for this query or if I was merely OCDing. Nevertheless, I discovered this discrepancy during testing and I thought I'd create an issue before 5.6.0 is released in case people thought it's a problem for them too. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3116#issuecomment-1131332496 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3116/1131332496(a)github.com>

I am closing this one because it was a useless conversion for this case and value overflow from int point of view. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3116#issuecomment-1132920385 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3116/1132920385(a)github.com>

To anyone else stumbling upon this, I solved my issue by using the following transformation: ``` $(vn(ru_164_dest_noccgr){sql.val}{s.unquote}) ``` instead of: ``` $(vn(ru_164_dest_noccgr){s.int}) ``` Thanks to everyone who looked into this! -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3116#issuecomment-1133794041 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3116/1133794041(a)github.com>