[Bug 2100887] Re: SRU: time_t overflow on certain architectures (100% CPU)

[Dave Jones]

Coming back to this in another patch pilot shift, I'm sorely tempted to
mark this "incomplete" until someone can come up with a reliable way to
actually replicate the issue. However ... at the same time, the fix is
trivial and quite clearly correcting something wrong (long != 64-bits on
armhf, or any 32-bit arch I'm aware of for that matter).

Maybe it's sufficient this fixes things for the original reporter (or
Armbian users more generally)? I'm going to sponsor this, and add a
caveat to the test plan that this can't be directly replicated on
Ubuntu, so testing should be done there to avoid regression more
generally, but testing of the fix will need to be done on affected
platforms.

** Description changed:

  [IMPACT]
  
  The version of acng in noble results in 100% load on a single core on 32
  bit platforms like armhf.  The reason is explained at the Debian BTS and
  further below at "ORIGINAL REPORT".
  
  [TEST CASE]
  
+ On affected platforms (Armbian?):
+ 
  Install noble on a 32-bit platform.  armhf lends itself nicely as being
  widely available in the form of older Raspberries and clones.  Install
  the unpatched version of apt-cacher-ng.  Start the apt-cacher-ng service
  and wait for a few minutes and you should see one core being blocked at
  100%.  Then compile the fix as provided in the debdiff and install.  The
  problem should go away.
+ 
+ On Ubuntu (which doesn't appear affected, but to guard against
+ regression):
+ 
+ * To be repeated for both 32-bit and 64-bit archs, e.g. armhf and arm64
+ * Install noble on boot media (e.g. SD card)
+ * Boot and enable proposed (https://wiki.ubuntu.com/Testing/EnableProposed)
+ * sudo apt install -t noble-proposed apt-cacher-ng
+ * sudo systemctl start apt-cacher-ng
+ * echo 'Acquire::http { Proxy "http://localhost:3142"; }' > /etc/apt/apt.conf.d/00proxy
+ * sudo apt update
+ * sudo apt upgrade
+ * Ensure update and upgrade proceed normally and no cores are pegged afterward
  
  [REGRESSION POTENTIAL]
  
  the patch was taken from upstream and backported to noble, but I can't
  comment further on potential regressions
  
  [ORIGINAL REPORT]
  
  Helge Deller reported to the Debian BTS a problem affecting certain
  platforms including armhf that lead to acng consuming 100% on one core.
  This was fixed already in the latest upstream release 3.7.5 which has
  already landed in o-series and p-series.  I kindly ask for an SRU to at
  least noble.  Jammy is most likely not affected.
  
  From the original bug report:
  "A few weeks back Debian moved to using a 64-bit time_t type
  even on 32-bit platforms. Since then I noticed that apt-cacher-ng
  will at some point starting to spin with using 100% CPU load, and
  stop doing any further apt-cacher-ng functionality like downloads.
  
  Today I found time to debug the issue, and the attached patch fixes
  it for me on the hppa platform. I'm sure other 32-bit arches like
  armhf and armel suffer from the same problem.
  The problem is, that during cleanup phase apt-cacher-ng will wait like this:
  
  -               wait_for(g, std::min(long(delta), long(84600)), 1);
  
  Above you can see that delta and 84600 will be converted to "long" type.
  A "long" type on 32-bit platforms is limited to 32-bit. On 64-bit
  platforms this is 64-bit, which is why 64-bit arches are not affected.
  So, after we now use 64-bit time_t values on 32-bit, the 64-bit values
  gets truncated to 32-bit and will wait too long if "delta" is a huge negative
  value.
  This is how to fix it:
  
  +               wait_for(g, std::min((time_t)(delta), (time_t)(84600)),
  1);
  
  [UBUNTU+1]
  
  This affects ports.ubuntu.com for example for armbian noble and is
  already fixed in o-series and p-series.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2100887

Title:
  SRU: time_t overflow on certain architectures (100% CPU)

Status in apt-cacher-ng package in Ubuntu:
  Fix Released
Status in apt-cacher-ng source package in Noble:
  New
Status in apt-cacher-ng package in Debian:
  Fix Released

Bug description:
  [IMPACT]

  The version of acng in noble results in 100% load on a single core on
  32 bit platforms like armhf.  The reason is explained at the Debian
  BTS and further below at "ORIGINAL REPORT".

  [TEST CASE]

  On affected platforms (Armbian?):

  Install noble on a 32-bit platform.  armhf lends itself nicely as
  being widely available in the form of older Raspberries and clones.
  Install the unpatched version of apt-cacher-ng.  Start the apt-cacher-
  ng service and wait for a few minutes and you should see one core
  being blocked at 100%.  Then compile the fix as provided in the
  debdiff and install.  The problem should go away.

  On Ubuntu (which doesn't appear affected, but to guard against
  regression):

  * To be repeated for both 32-bit and 64-bit archs, e.g. armhf and arm64
  * Install noble on boot media (e.g. SD card)
  * Boot and enable proposed (https://wiki.ubuntu.com/Testing/EnableProposed)
  * sudo apt install -t noble-proposed apt-cacher-ng
  * sudo systemctl start apt-cacher-ng
  * echo 'Acquire::http { Proxy "http://localhost:3142"; }' > /etc/apt/apt.conf.d/00proxy
  * sudo apt update
  * sudo apt upgrade
  * Ensure update and upgrade proceed normally and no cores are pegged afterward

  [REGRESSION POTENTIAL]

  the patch was taken from upstream and backported to noble, but I can't
  comment further on potential regressions

  [ORIGINAL REPORT]

  Helge Deller reported to the Debian BTS a problem affecting certain
  platforms including armhf that lead to acng consuming 100% on one
  core.  This was fixed already in the latest upstream release 3.7.5
  which has already landed in o-series and p-series.  I kindly ask for
  an SRU to at least noble.  Jammy is most likely not affected.

  From the original bug report:
  "A few weeks back Debian moved to using a 64-bit time_t type
  even on 32-bit platforms. Since then I noticed that apt-cacher-ng
  will at some point starting to spin with using 100% CPU load, and
  stop doing any further apt-cacher-ng functionality like downloads.

  Today I found time to debug the issue, and the attached patch fixes
  it for me on the hppa platform. I'm sure other 32-bit arches like
  armhf and armel suffer from the same problem.
  The problem is, that during cleanup phase apt-cacher-ng will wait like this:

  -               wait_for(g, std::min(long(delta), long(84600)), 1);

  Above you can see that delta and 84600 will be converted to "long" type.
  A "long" type on 32-bit platforms is limited to 32-bit. On 64-bit
  platforms this is 64-bit, which is why 64-bit arches are not affected.
  So, after we now use 64-bit time_t values on 32-bit, the 64-bit values
  gets truncated to 32-bit and will wait too long if "delta" is a huge negative
  value.
  This is how to fix it:

  +               wait_for(g, std::min((time_t)(delta),
  (time_t)(84600)), 1);

  [UBUNTU+1]

  This affects ports.ubuntu.com for example for armbian noble and is
  already fixed in o-series and p-series.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt-cacher-ng/+bug/2100887/+subscriptions