Fix crash when system reports huge load averages#100
Merged
Atoptool merged 1 commit intoAtoptool:masterfrom Feb 22, 2020
Merged
Fix crash when system reports huge load averages#100Atoptool merged 1 commit intoAtoptool:masterfrom
Atoptool merged 1 commit intoAtoptool:masterfrom
Conversation
The load average reporting functions in showsys.c use static buffer
sizes. When the load averages on a machine are very large, this causes
the writes to extend past the buffer. With this commit, if a number is
too large then we just show '>NNNNNN'. I'm not sure if this is the best
choice, so I'm open to other ideas.
This is what the output looks like when we exceed the maximums:
CPL | avg1 >999999 | avg5 >999999 | avg15 >99999 | csw 103117e3 | intr 88296e3 |
Note that this was triggered from a kernel that is reporting clearly
inaccurate numbers:
$ cat /proc/loadavg
1.25 2.40 368567045.47 1/589 53576
But regardless, crashing is no fun.
For future reference, I narrowed down the issue by building with
-fsanitize=address. For example:
==55396==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c527d6f14f at pc 0x7f4729942df9 bp 0x7ffe1fd30710 sp 0x7ffe1fd2fea0
WRITE of size 10 at 0x55c527d6f14f thread T0
#0 0x7f4729942df8 in __interceptor_vsprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1627
Atoptool#1 0x7f47299432cf in __interceptor_sprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1670
Atoptool#2 0x55c527d1c167 in sysprt_CPLAVG15 (/home/kapheine/projects/atop/atop+0x74167)
Atoptool#3 0x55c527d2087a in showsysline (/home/kapheine/projects/atop/atop+0x7887a)
Atoptool#4 0x55c527d1471f in prisyst (/home/kapheine/projects/atop/atop+0x6c71f)
Atoptool#5 0x55c527d090ff in generic_samp (/home/kapheine/projects/atop/atop+0x610ff)
Atoptool#6 0x55c527ce17c9 in main (/home/kapheine/projects/atop/atop+0x397c9)
Atoptool#7 0x7f472952a022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
Atoptool#8 0x55c527ce266d in _start (/home/kapheine/projects/atop/atop+0x3a66d)
0x55c527d6f14f is located 49 bytes to the left of global variable 'buf' defined in 'showsys.c:981:54' (0x55c527d6f180) of size 15
0x55c527d6f14f is located 0 bytes to the right of global variable 'buf' defined in 'showsys.c:1000:54' (0x55c527d6f140) of size 15
Owner
|
Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The load average reporting functions in showsys.c use static buffer
sizes. When the load averages on a machine are very large, this causes
the writes to extend past the buffer. With this commit, if a number is
too large then we just show '>NNNNNN'. I'm not sure if this is the best
choice, so I'm open to other ideas.
This is what the output looks like when we exceed the maximums:
CPL | avg1 >999999 | avg5 >999999 | avg15 >99999 | csw 103117e3 | intr 88296e3 |Note that this was triggered from a kernel that is reporting clearly
inaccurate numbers:
But regardless, crashing is no fun.
For future reference, I narrowed down the issue by building with
-fsanitize=address. For example: