GNU bug report logs - #24091
24.5; High CPU usage at startup while hidden

Previous Next

Package: emacs;

Reported by: aiken <acairncross <at> gmail.com>

Date: Wed, 27 Jul 2016 23:25:01 UTC

Severity: normal

Tags: confirmed, fixed, patch

Merged with 20335

Found in versions 24.4, 24.5, 25.1-rc1

Fixed in version 26.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acairncross <at> gmail.com, clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
Subject: Re: bug#24091: 24.5; High CPU usage at startup while hidden
Date: Sat, 30 Jul 2016 09:54:55 -0400
On Fri, Jul 29, 2016 at 1:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: npostavs <at> users.sourceforge.net
>> Date: Thu, 28 Jul 2016 21:45:55 -0400
>> Cc: clement.pit <at> gmail.com, 24091 <at> debbugs.gnu.org
>>
>> I guess we would like Emacs to hit this case:
>>
>>         /* If on another desktop, the deiconify/map may be ignored and the
>>            frame never becomes visible.  XMonad does this.
>>            Prevent an endless loop.  */
>>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>>           break;
>>
>> But it seems that FRAME_ICONIFIED_P is returning false, because I see
>> that tries is never incremented.
>
> The question is: what happens if you bypass that loop and let Emacs
> proceed with startup?  Does it successfully finish the startup, or
> does it error out or crash later on?

Works fine, no crashes.

>
> If the former, we need to find a way to detect this special situation,
> and maybe bypass the loop altogether.

Hmm, not really sure where to start.




This bug report was last modified 7 years and 264 days ago.

Previous Next


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