GNU bug report logs - #55628
debug-timer-check fails on macOS 11.6.6

Previous Next

Full log

Message #20 received at 55628 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 55628 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#55628: debug-timer-check fails on macOS 11.6.6
Date: Wed, 25 May 2022 20:11:16 +0300

> Resent-From: Mattias Engdegård <mattiase <at> acm.org>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Cc: 55628 <at> debbugs.gnu.org
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 25 May 2022 17:34:57 +0200
> 
> 25 maj 2022 kl. 15.05 skrev Mattias Engdegård <mattiase <at> acm.org>:
> 
> > More digging shows that set_alarm always sets the interval timer to at least 1 ms in the future even if the timer has expired.
> 
> In fact it was even worse than that: because of a second bug, the timer was then immediately reset to at least 1 s in the future. The proposed patch fixes both flaws.

Btw, this test will never work on a platform that only has setitimer,
because only one ITIMER_REAL timer is guaranteed to exist, and the
function attempts to arm 10 timers at the same time.

> Good to have a test for it -- maybe it should always be enabled, not just with enable-checking? People don't always reconfigure, rebuild and re-run the tests with enable-checking, nor do any of the build bots.

We don't usually have testing code in a production build, so why make
an exception here?  Especially since atimers are an obscure feature
used internally by Emacs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.