swanctl daemon stats information interpretes unsigned number as signed
"swanctl -S" interprets the sbrk and used counters as signed, but they are unsigned.
See the snippet below for the output of "swanctl -S".
┌─[root][thermi-pc][/home/thermi] └──╼ swanctl -S uptime: 50 minutes, since Mar 11 16:21:53 2015 worker threads: 128 total, 99 idle, working: 20/0/9/0 job queues: 0/0/0/0 jobs scheduled: 210323 IKE_SAs: 104867 total, 4 half-open mallinfo: sbrk -1821679616, mmap 3153920, used -1823622048, free 1942432
#1 Updated by Tobias Brunner over 7 years ago
- Tracker changed from Issue to Bug
- Category set to libcharon
- Status changed from New to Feedback
- Assignee set to Tobias Brunner
- Target version set to 5.3.0
- Resolution set to Fixed
Interesting, according to
man mallinfo the members of
struct mallinfo are actually defined as int. But it also lists the following BUG:
The fields of the mallinfo structure are typed as int. However,
because some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
vici_query.c currently uses
%d to print these values (as does
stroke_list.c). I guess we could use
%u as they are not meant to get negative (see the referenced commits).
But as stated above this will still not always result in accurate numbers. On a 64-bit Linux system an int is 4 bytes while a long is 8 bytes so at most 4 GB of allocations can be tracked, beyond that the numbers will be way too small. We can't do much about that though (we could use
malloc_info(3) but we'd have to parse the returned XML afterwards, eww).
#3 Updated by Tobias Brunner over 7 years ago
Well, so I guess swanctl should get the stats from some other kernel API then?
The information printed is not from the kernel, but from the C library's memory allocator (see
man mallinfo for details). As mentioned, there is an alternative when using glibc (
malloc_info), which I guess produces the correct numbers, but parsing XML data just for this information is currently no option. Anyway, it will take quite some load until charon actually uses 4 GB of memory.