Bug#1069859: atop: Fix atop for 64-bit time_t on arm
On Sun, May 26, 2024 at 06:12:50PM +0200, Marc Haber wrote: > I am not too fond about the suggested patch since it breaks atop on > systems with 32bit time_t, It does not: promoting the time_t to a long long on all architectures before passing it as an argument to the format string is portable to all (existing) architectures. Either sizeof(time_t) == sizeof(long long) and the cast is a no-op, or sizeof(time_t) < sizeof(long long) and this is merely a signed extension operation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1069859: atop: Fix atop for 64-bit time_t on arm
Control: tags -1 confirmed Control: forwarded -1 https://github.com/Atoptool/atop/issues/306 thanks thanks for spotting and debugging this. On Thu, Apr 25, 2024 at 02:16:33PM -0700, Steve Langasek wrote: > Although atop currently builds successfully on armhf and armel, it is broken > at runtime because it tries to use a time_t in a format string which now no > longer uses the correct size for the data. This was found in Ubuntu via > autopkgtests (unfortunately, Debian does not run autopkgtests for binNMUs): At least this superficial test did its job to uncover this issue. I'm quite happy about that. I can reproduce the issue and disagree with the classification as an RC bug. THe normal atop usage doesn't seem affected, only the -P option is broken. This doesnt make the package unustable for everbody. My apologies for letting this lay for a month, I was busy elsewhere in my life. I am not too fond about the suggested patch since it breaks atop on systems with 32bit time_t, which is not nice to backporters. I have asked Upstream whether they would be up for a less invasive fix. I intend to let this rest until the middle of the next week. Greetings Marc
Bug#1069859: atop: Fix atop for 64-bit time_t on arm
Package: atop Version: 2.10.0-2 Severity: grave Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Hi Marc, Although atop currently builds successfully on armhf and armel, it is broken at runtime because it tries to use a time_t in a format string which now no longer uses the correct size for the data. This was found in Ubuntu via autopkgtests (unfortunately, Debian does not run autopkgtests for binNMUs): 358s /tmp/autopkgtest.Nzaczp/build.Xps/src/debian/tests/01-numcpus: line 15: 1136 Segmentation fault (core dumped) atop -P cpu 5 1 1>&2 Please see attached a patch that fixes this issue. It has been uploaded to Ubuntu. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru atop-2.10.0/debian/patches/64-bit-time-t-compat.patch atop-2.10.0/debian/patches/64-bit-time-t-compat.patch --- atop-2.10.0/debian/patches/64-bit-time-t-compat.patch 1969-12-31 16:00:00.0 -0800 +++ atop-2.10.0/debian/patches/64-bit-time-t-compat.patch 2024-03-22 11:11:06.0 -0700 @@ -0,0 +1,22 @@ +Description: compatibility with 64-bit time_t +Author: Steve Langasek +Forwarded: no +Last-Update: 2024-03-22 + +Index: atop-2.10.0/parseable.c +=== +--- atop-2.10.0.orig/parseable.c atop-2.10.0/parseable.c +@@ -214,10 +214,10 @@ + convdate(curtime, datestr); + convtime(curtime, timestr); + +- snprintf(header, sizeof header, "%s %s %ld %s %s %d", ++ snprintf(header, sizeof header, "%s %s %lld %s %s %d", + labeldef[i].label, + utsname.nodename, +- curtime, ++ (long long)curtime, + datestr, timestr, numsecs); + + /* diff -Nru atop-2.10.0/debian/patches/series atop-2.10.0/debian/patches/series --- atop-2.10.0/debian/patches/series 2024-01-14 12:18:53.0 -0800 +++ atop-2.10.0/debian/patches/series 2024-03-22 11:10:13.0 -0700 @@ -15,3 +15,4 @@ no-atopgpud handle-default-file default +64-bit-time-t-compat.patch
