From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: edouard debry Newsgroups: gmane.emacs.bugs Subject: bug#45751: [feature/native-comp] emacs keeps running 100% of CPU Date: Tue, 12 Jan 2021 11:00:01 +0100 Message-ID: References: <87k0slu13n.fsf@gmail.com> <87im84jsu0.fsf@gmail.com> <87sg77yat7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b5352d05b8b116af" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40606"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45751@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 12 11:41:54 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzH7a-000AT6-Hn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Jan 2021 11:41:54 +0100 Original-Received: from localhost ([::1]:34598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzH7Z-0006Oq-JA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Jan 2021 05:41:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzGU3-0007qu-Hd for bug-gnu-emacs@gnu.org; Tue, 12 Jan 2021 05:01:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kzGU2-0005RE-81 for bug-gnu-emacs@gnu.org; Tue, 12 Jan 2021 05:01:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kzGU2-0005q7-4h for bug-gnu-emacs@gnu.org; Tue, 12 Jan 2021 05:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: edouard debry Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Jan 2021 10:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45751 X-GNU-PR-Package: emacs Original-Received: via spool by 45751-submit@debbugs.gnu.org id=B45751.161044562322376 (code B ref 45751); Tue, 12 Jan 2021 10:01:02 +0000 Original-Received: (at 45751) by debbugs.gnu.org; 12 Jan 2021 10:00:23 +0000 Original-Received: from localhost ([127.0.0.1]:59346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kzGTO-0005oo-Q3 for submit@debbugs.gnu.org; Tue, 12 Jan 2021 05:00:23 -0500 Original-Received: from mail-ej1-f53.google.com ([209.85.218.53]:34490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kzGTL-0005oT-Ax for 45751@debbugs.gnu.org; Tue, 12 Jan 2021 05:00:21 -0500 Original-Received: by mail-ej1-f53.google.com with SMTP id g20so2677245ejb.1 for <45751@debbugs.gnu.org>; Tue, 12 Jan 2021 02:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zAfWXcU4cZ3rpgkJCaRcs7yPOEciS/y7Frc8ruFqRDE=; b=DC23Rpvz702gEulBwKv3tUDJVMxiKhTY6Iw+ZBB34+z1l7zYaY8deRvWpPwc9Zjrsm kXjfK/8zY4oXoXHcYPCWsSO8yJa/QVhR3I9ma9sZH35wgAPhPHKSTfZlKutrkiKxZ5Ph 4CaFruf4MC7iFxyMjuXIWq7PQH3ewQ4rBv32ErZEUSSYzFjCNNqPkxkNT+zHeH4kxXTo 8llzWiEBo1H3uoj2JLq4UoaUs8wYa9YpxXHmQRIgMOUr317lrcD4cCI/Onl6Oc+pYi/E R10xEsfNZcZReBiwVv0muu4dPVXbn8ze9WCtwZxR20aI2uaiF0dndw2uq3PVx2z+WY+t FS1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zAfWXcU4cZ3rpgkJCaRcs7yPOEciS/y7Frc8ruFqRDE=; b=aQBAdbVDCcWzoVTK6D+eq43MQvIOp2LurRGuRCNo+jKrRJ8AULO9viERff45/MKYZD gHuYLmnWNWfqaKnAGdGYAZps8uNEfY+udtGsiLFHqTIwqrDeJSuelQjBMJUGn9xH6Yzi QsZ0BJ0n7UohGciVZ+WFkqwIqIvepNoBTioFKG+I2GraK2joogVjf26bYFLeL01lIaAU P4nqGKHh7Q9qMPjJNl4Qw4M0udLog44zbult4sAsDX2g+ZIFHLvpVbzCy8cBU7zQvC8D c7YIRBJvSwA8Wwa/+ycjc8Ng3HmdbR0tT/KUGbNu1dYIL0VamRerbMmH6BvODiWVeS/O IFWA== X-Gm-Message-State: AOAM530FlvlvV2tK+GNAEziBIKW39OpgcYzEf91O9e3z/uB9NMg4Ga0l UCM4ksrCzqM+u1xVnQ0axaEE7P4LWDyy8srRqPo= X-Google-Smtp-Source: ABdhPJxpVJBW4Poh6s2xDElrdmgYREm9goeZOgF+iUsrJcGGwOaWsLhiu43ZjBMq3BY2JBYqu0qOdNODzzEP/iiBVYE= X-Received: by 2002:a17:906:2e16:: with SMTP id n22mr2695931eji.477.1610445613248; Tue, 12 Jan 2021 02:00:13 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197781 Archived-At: --000000000000b5352d05b8b116af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D> 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'." #)('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) #)) (declare-function . byte-compile-macroexpand-declare-function) (eval-when-compile . #f(compiled-function (&rest body) #)) (eval-and-compile . #f(compiled-function (&rest body) #)) (with-suppressed-warnings . #f(compiled-function (warnings &rest body) #)))) macroexp-macroexpand((define-obsolete-variable-alias 'sml/time-format 'display-time-format) ((sml/-debug . #f(compiled-function (fmt &rest r) #)) (declare-function . byte-compile-macroexpand-declare-function) (eval-when-compile . #f(compiled-function (&rest body) #)) (eval-and-compile . #f(compiled-function (&rest body) #)) (with-suppressed-warnings . #f(compiled-function (warnings &rest body) #)))) byte-compile-recurse-toplevel((define-obsolete-variable-alias 'sml/time-format 'display-time-format) #) byte-compile-toplevel-file-form((define-obsolete-variable-alias 'sml/time-format 'display-time-format)) #(#) byte-compile-from-buffer(#) 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." #)("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...") apply(#f(compiled-function (filename) "Byte-compile FILENAME spilling data from the byte compiler." #) "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) #)(comp-spill-lap) mapc(#f(compiled-function (pass) #) (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() <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D> Le lun. 11 janv. 2021 =C3=A0 15:48, Andrea Corallo a =C3=A9c= rit : > =C3=89douard Debry writes: > > > On lun., janv. 11 2021, Andrea Corallo wrote: > >> =C3=89douard Debry writes: > >> > >>> On dim., janv. 10 2021, Andrea Corallo wrote: > >>>> =C3=89douard Debry 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 : > >>>>> > >>>>> <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D> > >>>>> 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 > --000000000000b5352d05b8b116af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tried on windows.

Indeed, wi= th 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 &q= uot;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 pr= oblem with emacs 28.0.50 ?

Regards
<= br>
<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
Compiling c:/Users/xxx/= .emacs.d/elpa/smart-mode-line-20190527.1156/smart-mode-line.el...
Debugg= er entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)
=C2=A0 #f(= compiled-function (obsolete-name current-name when &optional docstring)= "Make OBSOLETE-NAME a variable alias for CURRENT-NAME and mark it obs= olete.\n\nWHEN should be a string indicating when the variable was first\nm= ade obsolete, for example a date or a release number.\n\nThis macro evaluat= es all its parameters, and both OBSOLETE-NAME\nand CURRENT-NAME should be s= ymbols, so a typical usage would look like:\n\n =C2=A0(define-obsolete-vari= able-alias 'foo-thing 'bar-thing \"27.1\")\n\nThis macro = uses `defvaralias' and `make-obsolete-variable' (which see).\nSee t= he Info node `(elisp)Variable Aliases' for more details.\n\nIf CURRENT-= NAME is a defcustom or a defvar (more generally, any variable\nwhere OBSOLE= TE-NAME may be set, e.g. in an init file, before the\nalias is defined), th= en the define-obsolete-variable-alias\nstatement should be evaluated before= the defcustom, if user\ncustomizations are to be respected.=C2=A0 The simp= lest way to achieve\nthis is to place the alias statement before the defcus= tom (this\nis not necessary for aliases that are autoloaded, or in files\nd= umped with Emacs).=C2=A0 This is so that any user customizations are\nappli= ed before the defcustom tries to initialize the\nvariable (this is due to t= he way `defvaralias' works).\n\nFor the benefit of Customize, if OBSOLE= TE-NAME has\nany of the following properties, they are copied to\nCURRENT-N= AME, if it does not already have them:\n`saved-value', `saved-variable-= comment'." #<bytecode 0x127e504c6e942a72>)('sml/time-for= mat 'display-time-format)
=C2=A0 macroexpand((define-obsolete-variab= le-alias 'sml/time-format 'display-time-format) ((sml/-debug . #f(c= ompiled-function (fmt &rest r) #<bytecode -0x528c1381ccb3bab>)) (= declare-function . byte-compile-macroexpand-declare-function) (eval-when-co= mpile . #f(compiled-function (&rest body) #<bytecode -0xcee878b9e5c4= 79>)) (eval-and-compile . #f(compiled-function (&rest body) #<byt= ecode 0x31ea4933231cd9b>)) (with-suppressed-warnings . #f(compiled-funct= ion (warnings &rest body) #<bytecode 0x11867883d853666e>))))
= =C2=A0 macroexp-macroexpand((define-obsolete-variable-alias 'sml/time-f= ormat 'display-time-format) ((sml/-debug . #f(compiled-function (fmt &a= mp;rest r) #<bytecode -0x528c1381ccb3bab>)) (declare-function . byte-= compile-macroexpand-declare-function) (eval-when-compile . #f(compiled-func= tion (&rest body) #<bytecode -0xcee878b9e5c479>)) (eval-and-compi= le . #f(compiled-function (&rest body) #<bytecode 0x31ea4933231cd9b&= gt;)) (with-suppressed-warnings . #f(compiled-function (warnings &rest = body) #<bytecode 0x11867883d853666e>))))
=C2=A0 byte-compile-recur= se-toplevel((define-obsolete-variable-alias 'sml/time-format 'displ= ay-time-format) #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambd= a_45>)
=C2=A0 byte-compile-toplevel-file-form((define-obsolete-variab= le-alias 'sml/time-format 'display-time-format))
=C2=A0 #<sub= r F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_43>(#<buffer =C2= =A0*Compiler Input*>)
=C2=A0 byte-compile-from-buffer(#<buffer =C2= =A0*Compiler Input*>)
=C2=A0 byte-compile-file("c:/Users/xxx/.em= acs.d/elpa/smart-mode-line-2019...")
=C2=A0 #f(compiled-function (f= ilename) "Byte-compile FILENAME spilling data from the byte compiler.&= quot; #<bytecode 0x8fb180dc298647e>)("c:/Users/xxx/.emacs.d/elpa= /smart-mode-line-2019...")
=C2=A0 apply(#f(compiled-function (filen= ame) "Byte-compile FILENAME spilling data from the byte compiler."= ; #<bytecode 0x8fb180dc298647e>) "c:/Users/xxx/.emacs.d/elpa/sma= rt-mode-line-2019..." nil)
=C2=A0 comp-spill-lap-function("c:/= Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
=C2=A0 comp-spill= -lap("c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019...")
=C2= =A0 #f(compiled-function (pass) #<bytecode 0x1a1ac110a850427c>)(comp-= spill-lap)
=C2=A0 mapc(#f(compiled-function (pass) #<bytecode 0x1a1ac= 110a850427c>) (comp-spill-lap comp-limplify comp-fwprop comp-call-optim = comp-ipa-pure comp-add-cstrs comp-fwprop comp-dead-code comp-tco comp-fwpro= p comp-remove-type-hints comp-final))
=C2=A0 comp--native-compile("= c:/Users/xxx/.emacs.d/elpa/smart-mode-line-2019..." t)
=C2=A0 load-= with-code-conversion("c:/Users/xxx/AppData/Local/Temp/emacs-async-com.= .." "c:/Users/xxx/AppData/Local/Temp/emacs-async-com..." nil= t)
=C2=A0 command-line-1(("-l" "c:/Users/xxx/AppData/Loc= al/Temp/emacs-async-com..."))
=C2=A0 command-line()
=C2=A0 norma= l-top-level()
<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>



Le= =C2=A0lun. 11 janv. 2021 =C3=A0=C2=A015:48, Andrea Corallo <akrl@sdf.org> a =C3=A9crit=C2=A0:
=C3=89douard Debry <edouard.debry@gmail.c= om> writes:

> On lun., janv. 11 2021, Andrea Corallo wrote:
>> =C3=89douard Debry <edouard.debry@gmail.com> writes:
>>
>>> On dim., janv. 10 2021, Andrea Corallo wrote:
>>>> =C3=89douard Debry <edouard.debry@gmail.com> writes:
>>>>
>>>>> I noticed that when launching emacs on linux (debian b= uster),
>>>>> it keeps on running 100% of the CPU and seems to gradu= ally eat
>>>>> all
>>>>> memory, approximately 1-2% every minute.
>>>>>
>>>>> It seems related to native compiling. In the
>>>>> *Async-native-compile-log* I read :
>>>>>
>>>>> <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
>>>>> Compiling
>>>>> /home/edouard/.emacs.d/elpa/color-theme-sanityinc-sola= rized-20200805.603/color-theme-sanityinc-solarized.el...
>>>>
>>>> I see a similar issue with sanityinc-tomorrow.el, the comp= ilation
>>>> is
>>>> way
>>>> slower than any other one but it completes eventually.=C2= =A0 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'.=C2=A0 This is a sing= le function that
>>>> after
>>>> macro expansion becomes enormous.
>>>>
>>>> We need to make the compiler robust against these corner c= ases,
>>>> I'll
>>>> have a look this week into adding some logic for that.
>>>>
>>>> Thanks
>>>>
>>>>=C2=A0 =C2=A0Andrea
>>>
>>> I have waited for approximately one hour and until linux becam= e
>>> 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.

=C2=A0 Andrea
--000000000000b5352d05b8b116af--