a few questions on current development master

a few questions on current development master

[Alex Koval]

Hello,

I've been using emacs-27.0.50 built from git for quite a some time, no
issues were found until recently.

Yesterday I've installed the latest version from source and got a few
issues with it.

1) Memory issues. In almost no time it ate >6Gb of RSS and around 8GB or
   Virtual RAM. My OS: linux/arch, all default compilation options (no
   change to conigure flags).

   Just to compare it, I've worked with same code in same project but with
   emacs-26.1.92 for another 6 hours and it only consumed 1.2Gb so far.

   I will keep my eye on memory profiling, and will report more exact
   issues (profiler-start ram), any advice here? Also, quite strange
   that I've closed all buffers and still see that it consumes 6GB or
   RAM. Any documention how actually emacs returns RAM to host O/S ?

2) Compilation mode stopped 'catching' the lines:

   pycodestyle /home/k/tmp/a.py
   /home/k/tmp/a.py:5:1: E303 too many blank lines (3)


   When I try to press enter on any error, I get:

   In *Messages* buffer I see it:
   user-error: No error here

   (its also not highlited)

3) Wierd behavior of 'recentf-cleanup'. At first, it is disabled in my
config:

   '(recentf-auto-cleanup 'never)

   Also, I've even tried to 'hide' this function from visibility
   by redefining it in my config file as:

  (defun recentf-cleanup() (interactive))

   But it suddenly gots redefined after some period, and starts
   auto-execution quite often. For example current emacs session last
   for 5hrs and it already got executed 12 times (from *Messages*)

   Also, it does it quite aggressively, not paying attention to
   file-remote-p or anything else, trying to reopen all my tramp
   visited files one after one. That is quite strange.

   This is the most annoying thing because it came up often requiring me
   to press C-g many times until it actually stops looking to clean my
   old, remote, hidden by firewall files. The only workaround worked for
   me is to completely remove the recentf history file, so now this
   function has nothing to deal with.

Any hints on all above? I understand that I should not expect something
really stable from development version of emacs, but may be I can help
on narrowing down and fixing some of those issues?

Should I just report all those as separte bugs via M-x report-emacs-bug?

WBR,
   Alex

Re: a few questions on current development master

[Eli Zaretskii]

> From: Alex Koval <alex@koval.kharkov.ua>
> Date: Sun, 10 Mar 2019 19:28:35 +0200
> 
> 1) Memory issues. In almost no time it ate >6Gb of RSS and around 8GB or
>    Virtual RAM. My OS: linux/arch, all default compilation options (no
>    change to conigure flags).
> 
>    Just to compare it, I've worked with same code in same project but with
>    emacs-26.1.92 for another 6 hours and it only consumed 1.2Gb so far.
> 
>    I will keep my eye on memory profiling, and will report more exact
>    issues (profiler-start ram), any advice here?

My advice is not to use the memory profiling as a means to dig into
this problem.  Unlike its name, memory profiling has nothing to do
with profiling memory usage.

> Should I just report all those as separte bugs via M-x report-emacs-bug?

Yes, please.  With all the details you can provide, and preferably
starting from "emacs -Q".

Thanks.

Re: a few questions on current development master

[Stefan Monnier]

> 1) Memory issues. In almost no time it ate >6Gb of RSS and around 8GB or
>    Virtual RAM. My OS: linux/arch, all default compilation options (no
>    change to conigure flags).

Sounds like there's a bad leak.

>    I will keep my eye on memory profiling, and will report more exact
>    issues (profiler-start ram), any advice here?

We don't have a memory profiler: (profiler-start 'mem) simply uses
memory allocation as an approximation of time, but your problem is
likely not due to memory allocation but a lack of memory reclamation
(i.e. a leak).

>    Also, quite strange that I've closed all buffers and still see that
>    it consumes 6GB or RAM.  Any documention how actually emacs returns
>    RAM to host O/S ?

Returning memory to the OS can happen sometimes depending on lots of
different details, but it's basically irrelevant to your problem: If
there's a good reason why it got to 6GB, then returning to a smaller
size is good, but not indispensable.  In your particular situation, IIUC
Emacs should simply not have gotten to 6GB in the first place.

> Should I just report all those as separte bugs via M-x report-emacs-bug?

Yes, please,


        Stefan

Re: a few questions on current development master

[Daniel Pittman]

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

On Sun, Mar 10, 2019 at 1:29 PM Alex Koval <alex@koval.kharkov.ua> wrote:

> I've been using emacs-27.0.50 built from git for quite a some time, no
> issues were found until recently.
>
> Yesterday I've installed the latest version from source and got a few
> issues with it.
>
> 1) Memory issues. In almost no time it ate >6Gb of RSS and around 8GB or
>    Virtual RAM. My OS: linux/arch, all default compilation options (no
>    change to conigure flags).
>
>    Just to compare it, I've worked with same code in same project but with
>    emacs-26.1.92 for another 6 hours and it only consumed 1.2Gb so far.
>

FWIW, I checked my Emacs instance – uptime 3 days, 21 hours – and I have
112.8MB private memory, 196.6 total (including OS toolkit memory returnable
to the OS) on macOS.  So, while I'm uncertain what our comparative load is,
I'm definitely not seeing similar numbers on a build from last Thursday.
This is on macOS, but past experience says that platform is more likely,
not less, to show excessive memory use.

I'm assuming that this is almost all private memory (that is, a leak, as
Eli says) but
https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py will print
a useful summary and confirm that.

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