I hope this qualifies as "Bugs which do not fit under above categories, but (1) have an obviously safe patch"
** Description changed: 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); Can you please apply the patch to the next upload of apt-cacher-ng ?" This affects ports.ubuntu.com for example for armbian noble and is already fixed in o-series and p-series. + + + SRU TEMPLATE + + + [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 above. + + [TEST CASE] + + 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. 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. + + [REGRESSION POTENTIAL] + + the patch was taken from upstream and backported to noble, but I can't + comment further on potential regressions ** 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] + + 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. + + [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); Can you please apply the patch to the next upload of apt-cacher-ng ?" + [UBUNTU+1] + This affects ports.ubuntu.com for example for armbian noble and is already fixed in o-series and p-series. - - - SRU TEMPLATE - - - [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 above. - - [TEST CASE] - - 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. 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. - - [REGRESSION POTENTIAL] - - the patch was taken from upstream and backported to noble, but I can't - comment further on potential regressions ** 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] 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. [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); - Can you please apply the patch to the next upload of apt-cacher-ng ?" - [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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2100887 Title: SRU: time_t overflow on certain architectures (100% CPU) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-cacher-ng/+bug/2100887/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
