[sr-dev] [kamailio/kamailio] cfg_rpc updates changing variable values to large random numbers (#1583)

[vinesinha]

it's running on AWS EC2's Amazon Linux (which is based on Enterprise Red Hat Linux).

the output of `kamailio -I` is:

```
Print out of kamailio internals
  Version: kamailio 4.4.2 (x86_64/linux) 892ad6
  Default config: /xxxxxx/xxx/xxx/etc/kamailio/kamailio.cfg
  Default paths to modules: /xxxxxx/xxx/xxx/lib64/kamailio/modules
  Compile 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
  MAX_RECV_BUFFER_SIZE=262144
  MAX_LISTEN=16
  MAX_URI_SIZE=1024
  BUF_SIZE=65535
  DEFAULT PKG_SIZE=8MB
  DEFAULT SHM_SIZE=64MB
  ADAPTIVE_WAIT_LOOPS=1024
  TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select
  Source code revision ID: 892ad6
  Compiled with: x86_64-unknown-linux-gnu-gcc 4.9.4
  Compiled on: 16:57:00 Jun  5 2018
Thank you for flying kamailio!
```

just to confirm if gdb is not messing up something, I calculated the memory used inside the C file:

```
	int vin_block = sizeof(cfg_block_t);
	int vin_atom = sizeof(atomic_t);
	unsigned char v_vars[1];
	int vin_vars = sizeof(v_vars);

--- GDB output ---

(gdb) print vin_block
$1 = 8
(gdb) print vin_atom
$2 = 4
(gdb) print vin_vars
$3 = 1
```

This should be fine as gcc usually does padding as discussed here:
https://stackoverflow.com/questions/1841863/size-of-struct-in-c

So even if the sum of components is 5, it pads it to 8 (unless you have padding disabled in gcc). 
For, your case, where it's 9 ... it should actually be 12 if padding is enabled (this is enabled by default in gcc for many linux distros).

I'm not sure how the actual config variable mapping is done but it seems like the way it's being mapped, our variable ends up at the final 3 byte block (although the size is 4 bytes); which also means that there might be gaps in the middle of the memory block. However, this is just speculation. 

let me know if you need any further info. 




-- 
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/1583#issuecomment-402820932
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180705/423f38c2/attachment-0001.html>