Bug #886
swanctl daemon stats information interpretes unsigned number as signed
Description
"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
Associated revisions
vici: Use %u to print stats returned by mallinfo(3)
Fixes #886.
History
#1 Updated by Tobias Brunner almost 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.
stats() in vici_query.c currently uses %d to print these values (as does status() in 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).
#2 Updated by Noel Kuntze almost 7 years ago
Well, so I guess swanctl should get the stats from some other kernel API then?
#3 Updated by Tobias Brunner almost 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.
#4 Updated by Tobias Brunner almost 7 years ago
- Status changed from Feedback to Closed
stroke: Use %u to print stats returned by mallinfo(3)
References #886.