bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

I noticed that when launching emacs on linux (debian buster),
it keeps on running 100% of the CPU and seems to gradually eat all
memory, approximately 1-2% every minute.

It seems related to native compiling. In the 
*Async-native-compile-log* I read :

<=============================>
Compiling 
/home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...

In color-theme-sanityinc-solarized:
color-theme-sanityinc-solarized.el:850:14: Warning: assignment to 
free
    variable ‘ansi-color-names-vector’
color-theme-sanityinc-solarized.el:851:14: Warning: assignment to 
free
    variable ‘ansi-color-faces-vector’

In end of data:
color-theme-sanityinc-solarized.el:878:1: Warning: the function
    ‘color-theme-install’ is not known to be defined.
<============================>

Furthermore "ps x" gives :
 1395 pts/1    Rsl+   7:51 /usr/local/bin/emacs --batch -l 
 /tmp/emacs-async-comp-color-theme-sanityinc-solarized-ENplTN.el

If I kill this process or close the *Async-native-compile-log, 
then this disappears.

I do not understand what is the trouble with this package. The 
native compilation of
this package seems to be endless.

But this could be related to the previous bug "excessive memory 
..." as I use the
same package theme on windows 10.

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Édouard Debry <edouard.debry@gmail.com> writes:

> I noticed that when launching emacs on linux (debian buster),
> it keeps on running 100% of the CPU and seems to gradually eat all
> memory, approximately 1-2% every minute.
>
> It seems related to native compiling. In the
> *Async-native-compile-log* I read :
>
> <=============================>
> Compiling
> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...

I see a similar issue with sanityinc-tomorrow.el, the compilation is way
slower than any other one but it completes eventually.  I guess is the
same issue you see and with sufficient RAM also sanityinc-solarized
should complete.

In case of of sanityinc-tomorrow I think is because of
`color-theme-sanityinc-tomorrow'.  This is a single function that after
macro expansion becomes enormous.

We need to make the compiler robust against these corner cases, I'll
have a look this week into adding some logic for that.

Thanks

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On dim., janv. 10 2021, Andrea Corallo wrote:
> Édouard Debry <edouard.debry@gmail.com> writes:
>
>> I noticed that when launching emacs on linux (debian buster),
>> it keeps on running 100% of the CPU and seems to gradually eat 
>> all
>> memory, approximately 1-2% every minute.
>>
>> It seems related to native compiling. In the
>> *Async-native-compile-log* I read :
>>
>> <=============================>
>> Compiling
>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>
> I see a similar issue with sanityinc-tomorrow.el, the 
> compilation is way
> slower than any other one but it completes eventually.  I guess 
> is the
> same issue you see and with sufficient RAM also 
> sanityinc-solarized
> should complete.
>
> In case of of sanityinc-tomorrow I think is because of
> `color-theme-sanityinc-tomorrow'.  This is a single function 
> that after
> macro expansion becomes enormous.
>
> We need to make the compiler robust against these corner cases, 
> I'll
> have a look this week into adding some logic for that.
>
> Thanks
>
>   Andrea

I have waited for approximately one hour and until linux became 
totally unresponsive, I had to reboot.

I am not 100% sure it is because of emacs compiling the color 
theme package and eating all memory,
but I never had such a crash on linux since I own this laptop and 
I had exactly the same crash on
windows 10 with emacs native-comp eating all memory.

So most probably, my previous bug is related to that. I could try 
another theme and see if this still happens.

Regards

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On lun., janv. 11 2021, Édouard Debry wrote:
> On dim., janv. 10 2021, Andrea Corallo wrote:
>> Édouard Debry <edouard.debry@gmail.com> writes:
>>
>>> I noticed that when launching emacs on linux (debian buster),
>>> it keeps on running 100% of the CPU and seems to gradually eat 
>>> all
>>> memory, approximately 1-2% every minute.
>>>
>>> It seems related to native compiling. In the
>>> *Async-native-compile-log* I read :
>>>
>>> <=============================>
>>> Compiling
>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>
>> I see a similar issue with sanityinc-tomorrow.el, the 
>> compilation is way
>> slower than any other one but it completes eventually.  I guess 
>> is the
>> same issue you see and with sufficient RAM also 
>> sanityinc-solarized
>> should complete.
>>
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>> that after
>> macro expansion becomes enormous.
>>
>> We need to make the compiler robust against these corner cases, 
>> I'll
>> have a look this week into adding some logic for that.
>>
>> Thanks
>>
>>   Andrea
>
> I have waited for approximately one hour and until linux became 
> totally unresponsive, I
> had to reboot.
>
> I am not 100% sure it is because of emacs compiling the color 
> theme package and eating
> all memory,
> but I never had such a crash on linux since I own this laptop 
> and I had exactly the same
> crash on
> windows 10 with emacs native-comp eating all memory.
>
> So most probably, my previous bug is related to that. I could 
> try another theme and see
> if this still happens.
>
> Regards

Also, is there a way to prevent emacs native-comp to compile some 
packages, some kind
of blacklist. I would prefer at the moment because I am used to 
this color theme.

Do you think there may be a noticeable difference on emacs's 
performance between a
color theme natively compiled (*eln) or just byte compiled (*elc)

Regards

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Eli Zaretskii]

> Date: Sun, 10 Jan 2021 20:14:53 +0000
> Cc: 45751@debbugs.gnu.org
> From: Andrea Corallo via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> > Compiling
> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
> 
> I see a similar issue with sanityinc-tomorrow.el, the compilation is way
> slower than any other one but it completes eventually.  I guess is the
> same issue you see and with sufficient RAM also sanityinc-solarized
> should complete.
> 
> In case of of sanityinc-tomorrow I think is because of
> `color-theme-sanityinc-tomorrow'.  This is a single function that after
> macro expansion becomes enormous.
> 
> We need to make the compiler robust against these corner cases, I'll
> have a look this week into adding some logic for that.

Maybe we should have a "no-native-compile" cookie for these cases.
After all, compiling a theme will not really speed up anything
important, right?

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On lun., janv. 11 2021, Eli Zaretskii wrote:
>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>> Cc: 45751@debbugs.gnu.org
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> > Compiling
>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>> 
>> I see a similar issue with sanityinc-tomorrow.el, the 
>> compilation is way
>> slower than any other one but it completes eventually.  I guess 
>> is the
>> same issue you see and with sufficient RAM also 
>> sanityinc-solarized
>> should complete.
>> 
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>> that after
>> macro expansion becomes enormous.
>> 
>> We need to make the compiler robust against these corner cases, 
>> I'll
>> have a look this week into adding some logic for that.
>
> Maybe we should have a "no-native-compile" cookie for these 
> cases.
> After all, compiling a theme will not really speed up anything
> important, right?

This is more or less what I advocated with a native compile 
blacklist.

At the moment, it would help me if it is possible to toggle native 
compilation.
In my config file there is :

(setq package-native-compile t)

If I set it to nil, does it mean that, on startup, emacs will not 
try to natively compile
any packages ?

Regards

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On lun., janv. 11 2021, Édouard Debry wrote:
> On lun., janv. 11 2021, Eli Zaretskii wrote:
>>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>>> Cc: 45751@debbugs.gnu.org
>>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>  > Compiling
>>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>> I see a similar issue with sanityinc-tomorrow.el, the 
>>> compilation is way
>>> slower than any other one but it completes eventually.  I 
>>> guess is the
>>> same issue you see and with sufficient RAM also 
>>> sanityinc-solarized
>>> should complete.
>>> In case of of sanityinc-tomorrow I think is because of
>>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>>> that after
>>> macro expansion becomes enormous.
>>> We need to make the compiler robust against these corner 
>>> cases, I'll
>>> have a look this week into adding some logic for that.
>>
>> Maybe we should have a "no-native-compile" cookie for these 
>> cases.
>> After all, compiling a theme will not really speed up anything
>> important, right?
>
> This is more or less what I advocated with a native compile 
> blacklist.
>
> At the moment, it would help me if it is possible to toggle 
> native compilation.
> In my config file there is :
>
> (setq package-native-compile t)
>
> If I set it to nil, does it mean that, on startup, emacs will 
> not try to natively
> compile
> any packages ?

Answering to my own question, it seems that no. Is there an emacs 
command to kill the
native compiling process ? It seems that closing the log buffer 
has this effect, but there
is probably a better way.

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Édouard Debry <edouard.debry@gmail.com> writes:

> On dim., janv. 10 2021, Andrea Corallo wrote:
>> Édouard Debry <edouard.debry@gmail.com> writes:
>>
>>> I noticed that when launching emacs on linux (debian buster),
>>> it keeps on running 100% of the CPU and seems to gradually eat all
>>> memory, approximately 1-2% every minute.
>>>
>>> It seems related to native compiling. In the
>>> *Async-native-compile-log* I read :
>>>
>>> <=============================>
>>> Compiling
>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>
>> I see a similar issue with sanityinc-tomorrow.el, the compilation is
>> way
>> slower than any other one but it completes eventually.  I guess is
>> the
>> same issue you see and with sufficient RAM also sanityinc-solarized
>> should complete.
>>
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function that
>> after
>> macro expansion becomes enormous.
>>
>> We need to make the compiler robust against these corner cases, I'll
>> have a look this week into adding some logic for that.
>>
>> Thanks
>>
>>   Andrea
>
> I have waited for approximately one hour and until linux became
> totally unresponsive, I had to reboot.

Right, these are the classical symptoms of a system swapping for
insufficient physical memory (or excessive mem usage by a program :)

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Édouard Debry <edouard.debry@gmail.com> writes:

> On lun., janv. 11 2021, Édouard Debry wrote:
>> On dim., janv. 10 2021, Andrea Corallo wrote:
>>> Édouard Debry <edouard.debry@gmail.com> writes:
>>>
>>>> I noticed that when launching emacs on linux (debian buster),
>>>> it keeps on running 100% of the CPU and seems to gradually eat all
>>>> memory, approximately 1-2% every minute.
>>>>
>>>> It seems related to native compiling. In the
>>>> *Async-native-compile-log* I read :
>>>>
>>>> <=============================>
>>>> Compiling
>>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>>
>>> I see a similar issue with sanityinc-tomorrow.el, the compilation
>>> is way
>>> slower than any other one but it completes eventually.  I guess is
>>> the
>>> same issue you see and with sufficient RAM also sanityinc-solarized
>>> should complete.
>>>
>>> In case of of sanityinc-tomorrow I think is because of
>>> `color-theme-sanityinc-tomorrow'.  This is a single function that
>>> after
>>> macro expansion becomes enormous.
>>>
>>> We need to make the compiler robust against these corner cases,
>>> I'll
>>> have a look this week into adding some logic for that.
>>>
>>> Thanks
>>>
>>>   Andrea
>>
>> I have waited for approximately one hour and until linux became
>> totally unresponsive, I
>> had to reboot.
>>
>> I am not 100% sure it is because of emacs compiling the color theme
>> package and eating
>> all memory,
>> but I never had such a crash on linux since I own this laptop and I
>> had exactly the same
>> crash on
>> windows 10 with emacs native-comp eating all memory.
>>
>> So most probably, my previous bug is related to that. I could try
>> another theme and see
>> if this still happens.
>>
>> Regards
>
> Also, is there a way to prevent emacs native-comp to compile some
> packages, some kind
> of blacklist. I would prefer at the moment because I am used to this
> color theme.

Yes, `comp-deferred-compilation-deny-list'.

> Do you think there may be a noticeable difference on emacs's
> performance between a
> color theme natively compiled (*eln) or just byte compiled (*elc)

I don't think so.

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>> Cc: 45751@debbugs.gnu.org
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> > Compiling
>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>> 
>> I see a similar issue with sanityinc-tomorrow.el, the compilation is way
>> slower than any other one but it completes eventually.  I guess is the
>> same issue you see and with sufficient RAM also sanityinc-solarized
>> should complete.
>> 
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function that after
>> macro expansion becomes enormous.
>> 
>> We need to make the compiler robust against these corner cases, I'll
>> have a look this week into adding some logic for that.
>
> Maybe we should have a "no-native-compile" cookie for these cases.
> After all, compiling a theme will not really speed up anything
> important, right?

Agreed, that's a good idea.

At the moment similar mechanisms are:

- Declare a function with (declare (speed -1)) will include the
  function in the .eln but in byte-code form.

- Have comp-speed to -1 as file variable in the source file should
  produce an eln containing only byte-code functions.

But yeah, a dedicated cookie is better because there's no point of
producing the .eln file at all for cases like this.

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On lun., janv. 11 2021, Andrea Corallo wrote:
> Édouard Debry <edouard.debry@gmail.com> writes:
>
>> On lun., janv. 11 2021, Édouard Debry wrote:
>>> On dim., janv. 10 2021, Andrea Corallo wrote:
>>>> Édouard Debry <edouard.debry@gmail.com> writes:
>>>>
>>>>> I noticed that when launching emacs on linux (debian 
>>>>> buster),
>>>>> it keeps on running 100% of the CPU and seems to gradually 
>>>>> eat all
>>>>> memory, approximately 1-2% every minute.
>>>>>
>>>>> It seems related to native compiling. In the
>>>>> *Async-native-compile-log* I read :
>>>>>
>>>>> <=============================>
>>>>> Compiling
>>>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>>>
>>>> I see a similar issue with sanityinc-tomorrow.el, the 
>>>> compilation
>>>> is way
>>>> slower than any other one but it completes eventually.  I 
>>>> guess is
>>>> the
>>>> same issue you see and with sufficient RAM also 
>>>> sanityinc-solarized
>>>> should complete.
>>>>
>>>> In case of of sanityinc-tomorrow I think is because of
>>>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>>>> that
>>>> after
>>>> macro expansion becomes enormous.
>>>>
>>>> We need to make the compiler robust against these corner 
>>>> cases,
>>>> I'll
>>>> have a look this week into adding some logic for that.
>>>>
>>>> Thanks
>>>>
>>>>   Andrea
>>>
>>> I have waited for approximately one hour and until linux 
>>> became
>>> totally unresponsive, I
>>> had to reboot.
>>>
>>> I am not 100% sure it is because of emacs compiling the color 
>>> theme
>>> package and eating
>>> all memory,
>>> but I never had such a crash on linux since I own this laptop 
>>> and I
>>> had exactly the same
>>> crash on
>>> windows 10 with emacs native-comp eating all memory.
>>>
>>> So most probably, my previous bug is related to that. I could 
>>> try
>>> another theme and see
>>> if this still happens.
>>>
>>> Regards
>>
>> Also, is there a way to prevent emacs native-comp to compile 
>> some
>> packages, some kind
>> of blacklist. I would prefer at the moment because I am used to 
>> this
>> color theme.
>
> Yes, `comp-deferred-compilation-deny-list'.
>

Thanks ! In fact I just discovered this settings as you answered 
me and

(require 'comp)
(setq comp-deferred-compilation-deny-list '("color-theme-*"))

in my init file does the job.

>> Do you think there may be a noticeable difference on emacs's
>> performance between a
>> color theme natively compiled (*eln) or just byte compiled 
>> (*elc)
>
> I don't think so.
>
>   Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Édouard Debry]

On lun., janv. 11 2021, Andrea Corallo wrote:
> Édouard Debry <edouard.debry@gmail.com> writes:
>
>> On dim., janv. 10 2021, Andrea Corallo wrote:
>>> Édouard Debry <edouard.debry@gmail.com> writes:
>>>
>>>> I noticed that when launching emacs on linux (debian buster),
>>>> it keeps on running 100% of the CPU and seems to gradually 
>>>> eat all
>>>> memory, approximately 1-2% every minute.
>>>>
>>>> It seems related to native compiling. In the
>>>> *Async-native-compile-log* I read :
>>>>
>>>> <=============================>
>>>> Compiling
>>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>>
>>> I see a similar issue with sanityinc-tomorrow.el, the 
>>> compilation is
>>> way
>>> slower than any other one but it completes eventually.  I 
>>> guess is
>>> the
>>> same issue you see and with sufficient RAM also 
>>> sanityinc-solarized
>>> should complete.
>>>
>>> In case of of sanityinc-tomorrow I think is because of
>>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>>> that
>>> after
>>> macro expansion becomes enormous.
>>>
>>> We need to make the compiler robust against these corner 
>>> cases, I'll
>>> have a look this week into adding some logic for that.
>>>
>>> Thanks
>>>
>>>   Andrea
>>
>> I have waited for approximately one hour and until linux became
>> totally unresponsive, I had to reboot.
>
> Right, these are the classical symptoms of a system swapping for
> insufficient physical memory (or excessive mem usage by a 
> program :)

Probably, my previous bug report "Excessive memory ..." was due to 
this package
trying to be natively compiled. I will try the 
"comp-deferred-compilation-deny-list"
setting on windows 10 so as to be sure there is nothing more.

Regards

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Édouard Debry <edouard.debry@gmail.com> writes:

> On lun., janv. 11 2021, Andrea Corallo wrote:
>> Édouard Debry <edouard.debry@gmail.com> writes:
>>
>>> On dim., janv. 10 2021, Andrea Corallo wrote:
>>>> Édouard Debry <edouard.debry@gmail.com> writes:
>>>>
>>>>> I noticed that when launching emacs on linux (debian buster),
>>>>> it keeps on running 100% of the CPU and seems to gradually eat
>>>>> all
>>>>> memory, approximately 1-2% every minute.
>>>>>
>>>>> It seems related to native compiling. In the
>>>>> *Async-native-compile-log* I read :
>>>>>
>>>>> <=============================>
>>>>> Compiling
>>>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>>>
>>>> I see a similar issue with sanityinc-tomorrow.el, the compilation
>>>> is
>>>> way
>>>> slower than any other one but it completes eventually.  I guess is
>>>> the
>>>> same issue you see and with sufficient RAM also
>>>> sanityinc-solarized
>>>> should complete.
>>>>
>>>> In case of of sanityinc-tomorrow I think is because of
>>>> `color-theme-sanityinc-tomorrow'.  This is a single function that
>>>> after
>>>> macro expansion becomes enormous.
>>>>
>>>> We need to make the compiler robust against these corner cases,
>>>> I'll
>>>> have a look this week into adding some logic for that.
>>>>
>>>> Thanks
>>>>
>>>>   Andrea
>>>
>>> I have waited for approximately one hour and until linux became
>>> totally unresponsive, I had to reboot.
>>
>> Right, these are the classical symptoms of a system swapping for
>> insufficient physical memory (or excessive mem usage by a program :)
>
> Probably, my previous bug report "Excessive memory ..." was due to
> this package
> trying to be natively compiled. I will try the
> "comp-deferred-compilation-deny-list"
> setting on windows 10 so as to be sure there is nothing more.

Thanks, let us know so in case we can close the duplicate.

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[edouard debry]

[-- Attachment #1: Type: text/plain, Size: 7303 bytes --]

Tried on windows.

Indeed, with previous settings in my init file, I do not see anymore emacs
eating all memory, currently it remains at ~150Mo while idle.

The only trouble is that some packages fail to be natively compiled as
"smart-mode-line" with the same error :
Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)

I blacklisted this package too.

Details of the error follows, I presume this is a compatibility problem
with emacs 28.0.50 ?

Regards

<================================================================================>
Compiling
c:/Users/xxx/.emacs.d/elpa/smart-mode-line-20190527.1156/smart-mode-line.el...
Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)
  #f(compiled-function (obsolete-name current-name when &optional
docstring) "Make OBSOLETE-NAME a variable alias for CURRENT-NAME and mark
it obsolete.\n\nWHEN should be a string indicating when the variable was
first\nmade obsolete, for example a date or a release number.\n\nThis macro
evaluates all its parameters, and both OBSOLETE-NAME\nand CURRENT-NAME
should be symbols, so a typical usage would look like:\n\n
 (define-obsolete-variable-alias 'foo-thing 'bar-thing \"27.1\")\n\nThis
macro uses `defvaralias' and `make-obsolete-variable' (which see).\nSee the
Info node `(elisp)Variable Aliases' for more details.\n\nIf CURRENT-NAME is
a defcustom or a defvar (more generally, any variable\nwhere OBSOLETE-NAME
may be set, e.g. in an init file, before the\nalias is defined), then the
define-obsolete-variable-alias\nstatement should be evaluated before the
defcustom, if user\ncustomizations are to be respected.  The simplest way
to achieve\nthis is to place the alias statement before the defcustom
(this\nis not necessary for aliases that are autoloaded, or in
files\ndumped with Emacs).  This is so that any user customizations
are\napplied before the defcustom tries to initialize the\nvariable (this
is due to the way `defvaralias' works).\n\nFor the benefit of Customize, if
OBSOLETE-NAME has\nany of the following properties, they are copied
to\nCURRENT-NAME, if it does not already have them:\n`saved-value',
`saved-variable-comment'." #<bytecode 0x127e504c6e942a72>)('sml/time-format
'display-time-format)
  macroexpand((define-obsolete-variable-alias 'sml/time-format
'display-time-format) ((sml/-debug . #f(compiled-function (fmt &rest r)
#<bytecode -0x528c1381ccb3bab>)) (declare-function .
byte-compile-macroexpand-declare-function) (eval-when-compile .
#f(compiled-function (&rest body) #<bytecode -0xcee878b9e5c479>))
(eval-and-compile . #f(compiled-function (&rest body) #<bytecode
0x31ea4933231cd9b>)) (with-suppressed-warnings . #f(compiled-function
(warnings &rest body) #<bytecode 0x11867883d853666e>))))
  macroexp-macroexpand((define-obsolete-variable-alias 'sml/time-format
'display-time-format) ((sml/-debug . #f(compiled-function (fmt &rest r)
#<bytecode -0x528c1381ccb3bab>)) (declare-function .
byte-compile-macroexpand-declare-function) (eval-when-compile .
#f(compiled-function (&rest body) #<bytecode -0xcee878b9e5c479>))
(eval-and-compile . #f(compiled-function (&rest body) #<bytecode
0x31ea4933231cd9b>)) (with-suppressed-warnings . #f(compiled-function
(warnings &rest body) #<bytecode 0x11867883d853666e>))))
  byte-compile-recurse-toplevel((define-obsolete-variable-alias
'sml/time-format 'display-time-format) #<subr
F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_45>)
  byte-compile-toplevel-file-form((define-obsolete-variable-alias
'sml/time-format 'display-time-format))
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_43>(#<buffer
 *Compiler Input*>)
  byte-compile-from-buffer(#<buffer  *Compiler Input*>)
  byte-compile-file("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
  #f(compiled-function (filename) "Byte-compile FILENAME spilling data from
the byte compiler." #<bytecode
0x8fb180dc298647e>)("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
  apply(#f(compiled-function (filename) "Byte-compile FILENAME spilling
data from the byte compiler." #<bytecode 0x8fb180dc298647e>)
"c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019..." nil)

comp-spill-lap-function("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
  comp-spill-lap("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
  #f(compiled-function (pass) #<bytecode
0x1a1ac110a850427c>)(comp-spill-lap)
  mapc(#f(compiled-function (pass) #<bytecode 0x1a1ac110a850427c>)
(comp-spill-lap comp-limplify comp-fwprop comp-call-optim comp-ipa-pure
comp-add-cstrs comp-fwprop comp-dead-code comp-tco comp-fwprop
comp-remove-type-hints comp-final))
  comp--native-compile("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019..."
t)

load-with-code-conversion("c:/Users/xxx/AppData/Local/Temp/emacs-async-com..."
"c:/Users/xxx/AppData/Local/Temp/emacs-async-com..." nil t)
  command-line-1(("-l"
"c:/Users/xxx/AppData/Local/Temp/emacs-async-com..."))
  command-line()
  normal-top-level()
<==============================================================================>



Le lun. 11 janv. 2021 à 15:48, Andrea Corallo <akrl@sdf.org> a écrit :

> Édouard Debry <edouard.debry@gmail.com> writes:
>
> > On lun., janv. 11 2021, Andrea Corallo wrote:
> >> Édouard Debry <edouard.debry@gmail.com> writes:
> >>
> >>> On dim., janv. 10 2021, Andrea Corallo wrote:
> >>>> Édouard Debry <edouard.debry@gmail.com> writes:
> >>>>
> >>>>> I noticed that when launching emacs on linux (debian buster),
> >>>>> it keeps on running 100% of the CPU and seems to gradually eat
> >>>>> all
> >>>>> memory, approximately 1-2% every minute.
> >>>>>
> >>>>> It seems related to native compiling. In the
> >>>>> *Async-native-compile-log* I read :
> >>>>>
> >>>>> <=============================>
> >>>>> Compiling
> >>>>>
> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
> >>>>
> >>>> I see a similar issue with sanityinc-tomorrow.el, the compilation
> >>>> is
> >>>> way
> >>>> slower than any other one but it completes eventually.  I guess is
> >>>> the
> >>>> same issue you see and with sufficient RAM also
> >>>> sanityinc-solarized
> >>>> should complete.
> >>>>
> >>>> In case of of sanityinc-tomorrow I think is because of
> >>>> `color-theme-sanityinc-tomorrow'.  This is a single function that
> >>>> after
> >>>> macro expansion becomes enormous.
> >>>>
> >>>> We need to make the compiler robust against these corner cases,
> >>>> I'll
> >>>> have a look this week into adding some logic for that.
> >>>>
> >>>> Thanks
> >>>>
> >>>>   Andrea
> >>>
> >>> I have waited for approximately one hour and until linux became
> >>> totally unresponsive, I had to reboot.
> >>
> >> Right, these are the classical symptoms of a system swapping for
> >> insufficient physical memory (or excessive mem usage by a program :)
> >
> > Probably, my previous bug report "Excessive memory ..." was due to
> > this package
> > trying to be natively compiled. I will try the
> > "comp-deferred-compilation-deny-list"
> > setting on windows 10 so as to be sure there is nothing more.
>
> Thanks, let us know so in case we can close the duplicate.
>
>   Andrea
>

[-- Attachment #2: Type: text/html, Size: 9055 bytes --]

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

edouard debry <edouard.debry@gmail.com> writes:

> Tried on windows.
>
> Indeed, with previous settings in my init file, I do not see anymore emacs eating all memory, currently it remains at
> ~150Mo while idle.

Right so I'll merge with bug#45705.

> The only trouble is that some packages fail to be natively compiled as "smart-mode-line" with the same error :
> Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2) 
>
> I blacklisted this package too.
>
> Details of the error follows, I presume this is a compatibility problem with emacs 28.0.50 ?

Yes I think so.

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Édouard Debry <edouard.debry@gmail.com> writes:

> I noticed that when launching emacs on linux (debian buster),
> it keeps on running 100% of the CPU and seems to gradually eat all
> memory, approximately 1-2% every minute.
>
> It seems related to native compiling. In the
> *Async-native-compile-log* I read :
>
> <=============================>
> Compiling
> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...

Hi Édouard,

with 0ffb3dfaa4 I'm now able to compile
color-theme-sanityinc-solarized.el.

Could you check works for you too?

Thanks

  Andrea

bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

akrl--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Édouard Debry <edouard.debry@gmail.com> writes:
>
>> I noticed that when launching emacs on linux (debian buster),
>> it keeps on running 100% of the CPU and seems to gradually eat all
>> memory, approximately 1-2% every minute.
>>
>> It seems related to native compiling. In the
>> *Async-native-compile-log* I read :
>>
>> <=============================>
>> Compiling
>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>
> Hi Édouard,
>
> with 0ffb3dfaa4 I'm now able to compile
> color-theme-sanityinc-solarized.el.
>
> Could you check works for you too?

As for me is working and no feedback was provided I'm closing this.

Happy to re-open in case.

Thanks!

  Andrea