bug#41077: [feature/native-comp] virtual memory exhausted (was: bug#41077: [feature/native-comp] Segfaults when compiling ELC+ELN)

[Kévin Le Gouguec]

Andrea Corallo <akrl@sdf.org> writes:

> All versions should work but at this point I'd go for releases/gcc-10 or
> releases/gcc-9.3.0

Thanks, I went with 9.3.0.  Now the "ELC+ELN" steps start smoothly,
unfortunately I don't think the little buster can finish the job :(

I first ran a -j2 build which crashed after 14 hours while compiling
char-fold.elc.  I didn't get anything more precise than "virtual memory
exhausted: Cannot allocate memory" on the console.

Thinking it might help to compile only one file at a time, after
removing the temporary files related to char-fold.el[1], I started a -j1
build which picked up where the previous build left off, i.e. with
char-fold.elc.

Unfortunately that file alone seems to be too much for my system to
handle; compilation ended with the same "virtual memory exhausted" error
after less than an hour and a half.

I recorded some information related to memory usage during this second
run (cf. attached graph[2]).  My takeway is that at some point, the
compilation process's memory usage skyrockets, until the system's memory
(2GB RAM + 2GB swap) is completely exhausted.


I haven't reopened/created a new issue because I'm not sure there's a
way forward; let me know if you'd like me to perform some more in-depth
profiling.


[1] lisp/char-fold.elc… and lisp/eln-i686-pc-linux-gnu-…/char-fold….eln.

[2] The graph shows:
    - the VSZ of the process using the most virtual memory,
    - the RSS of the process using the most virtual memory,
    - the "available" column shown by free(1) on the "Mem:" line,
    - the "used" column shown by free(1) on the "Swap:" line,
    - the name of the process using the most virtual memory.

    Measurements were taken every minute.  I can upload the sources for
    this graph (measurement script, measurements, and plotting script)
    if that helps.

memory.png
Description: PNG image