Project

General

Profile

Bug #886

swanctl daemon stats information interpretes unsigned number as signed

Added by Noel Kuntze over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
11.03.2015
Due date:
Estimated time:
Affected version:
5.2.2
Resolution:
Fixed

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

Revision 8286e205 (diff)
Added by Tobias Brunner over 5 years ago

stroke: Use %u to print stats returned by mallinfo(3)

References #886.

Revision 6d41927b (diff)
Added by Tobias Brunner over 5 years ago

vici: Use %u to print stats returned by mallinfo(3)

Fixes #886.

History

#1 Updated by Tobias Brunner over 5 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 over 5 years ago

Well, so I guess swanctl should get the stats from some other kernel API then?

#3 Updated by Tobias Brunner over 5 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 over 5 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF