unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: edouard debry <edouard.debry@gmail.com>
To: Andrea Corallo <akrl@sdf.org>
Cc: 45751@debbugs.gnu.org
Subject: bug#45751: [feature/native-comp] emacs keeps running 100% of CPU
Date: Tue, 12 Jan 2021 11:00:01 +0100	[thread overview]
Message-ID: <CAMJA--b63GWDcNZfxFG7gHVBuFGoDWOCzXU88+Ps8xOEOx4-FA@mail.gmail.com> (raw)
In-Reply-To: <xjfczybfs12.fsf@sdf.org>

[-- 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 --]

  reply	other threads:[~2021-01-12 10:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-09 23:44 bug#45751: [feature/native-comp] emacs keeps running 100% of CPU Édouard Debry
2021-01-10 20:14 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-10 23:05   ` Édouard Debry
2021-01-10 23:10     ` Édouard Debry
2021-01-11 10:17       ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-11 11:23         ` Édouard Debry
2021-01-11 10:15     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-11 11:25       ` Édouard Debry
2021-01-11 14:48         ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-12 10:00           ` edouard debry [this message]
2021-01-12 10:56             ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-11  3:25   ` Eli Zaretskii
2021-01-11  8:02     ` Édouard Debry
2021-01-11  8:10       ` Édouard Debry
2021-01-11 10:25     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-19 21:04 ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-28  8:01   ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMJA--b63GWDcNZfxFG7gHVBuFGoDWOCzXU88+Ps8xOEOx4-FA@mail.gmail.com \
    --to=edouard.debry@gmail.com \
    --cc=45751@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).