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.