### Description
We are running Kamailio 5.1.x in a mixed native/Kemi environment. That means, most of the config is still native Kamailio language, but some newer functions were written in JS and included via `jsdt_run("...");`.
In one of those functions, we place an sqlops query. And since introducing this code, Kamailio leaks memory. Slowly, but eventually, the private memory will fill up.
### Troubleshooting
#### Reproduction
In Kamailio, the code looks like this: ``` if (!jsdt_run("ksrIsCallAccountingRequired", "$(var(accentries){s.select,10,|})", "$(var(accentries){s.select,12,|})")) { xlog("L_ERR", "JS Call of ksrIsCallAccountingRequired route failed.\n"); } ```
And our JS code containing sqlops looks like this: ``` extension = '1234567e0'; mastersipid = '1234567'; KSR.sqlops.sql_query( "dbconn", `SELECT username, grp FROM grp WHERE username IN ('${mastersipid}', '${extension}') AND grp = 'ourGroupName'`, user ); ```
For each call, this query is executed once. Depending on the traffic, you can see the private package memory starting to fill up quicker or slower.
#### Debugging Data
### Possible Solutions
We had a similar problem about two years ago with app_lua and getting entries from a hash table, which we solved by introducing a temporary variable for using in the hash table index instead of strings. We tried doing the same thing in our current setup:
``` KSR.pv.sets("$var(extensionForQuery)", extension); KSR.pv.sets("$var(masterSipidForQuery)", masterSipid); KSR.sqlops.sql_query( "dbconn", "SELECT username, grp FROM grp WHERE username IN ('$var(masterSipidForQuery)', '$var(extensionForQuery)') AND grp = 'ourGroupName'", user ); ```
However, Kamailio doesn't replace the variables in the query string. Although the documentation of the sqlops module says, it supports pseudovars in the query string. We even tried putting the whole query into a variable, but ended up with a sqlops error.
### Additional Information
``` ersion: kamailio 5.1.4 (x86_64/linux) 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_LISTEN 16, 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 4.7.2 ```
* **Operating System**:
``` Debian Wheezy (yeah, I know... ) ```
Hello Sebastian, thanks for the report. Do you observe this as well with 5.1.8 or latest 5.1 branch? There have been almost 450 commits since release of 5.1.4 to this branch.
What is the third parameter of the sql query function: `user`? A javascript variable that can have random value? If yes, then you create result containers for each of its values. You should use there a static string.
I pushed a patch to set an upper limit to the number of result containers that can be defined.
Probably there are couple of other places in different modules where a similar case can happen, because in the native kamailio.cfg such parameters are typically restricted to static string, expecting to be a few values for them across the script.
Thanks for opening our eyes once again, @miconda! We already thought of something like this, but got stuck in the second parameter. Indeed we set the user id as result identifier. We changed it to a static string now, I think the problem should disappear.
Closed #2032.