GNU bug report logs - #76705
31.0.50; igc: crash

Previous Next

Package: emacs;

Reported by: Óscar Fuentes <oscarfv <at> eclipso.eu>

Date: Mon, 3 Mar 2025 04:33:04 UTC

Severity: normal

Found in version 31.0.50

Full log


Message #35 received at 76705 <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <oscarfv <at> eclipso.eu>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 76705 <at> debbugs.gnu.org
Subject: Re: bug#76705: 31.0.50; igc: crash
Date: Mon, 03 Mar 2025 17:50:15 +0100
Pip Cet <pipcet <at> protonmail.com> writes:

>> $ objdump -h dump | grep " load" | wc
>>    9237   64659  747221
>
> Hmm. Is it possible that increases by a factor of 6 during a collection?
> How large is the core file?

$ ls -lh
total 2.8G
-rw-rw-r-- 1 oscar oscar 2.8G Mar  3 16:46 dump

>>> What is the output of
>>>
>>> cat /proc/sys/vm/max_map_count
>>>
>>> ?  It is 65530 here,
>>
>> Same here.
>
> I set it to 4096, and that crashed my MPS Emacs when I started a
> collection (which is when the mprotect calls happen), so running against
> this limit during a collection is my current best theory.
>
> If this is indeed an issue, we might have to increase ARENA_GRAIN_SIZE,
> or submit a patch to MPS...
>
> However, I would still like to see errno = ENOMEM to be sure :-)

Trying to follow Eli's hint:

(gdb) ptype errno
type = int
(gdb) whatis errno
type = int
(gdb) p errno
$1 = 25

ENOEM here is:

/usr/include/asm-generic/errno-base.h
16:#define      ENOMEM          12      /* Out of memory */

>>> Thanks! This means that it was actually ProtSet which aborted, and since
>>> it doesn't show up in the backtrace it must have tail-called the
>>> assertion function.  Can you disassemble ProtSet just to make sure that
>>> we're looking at an mprotect failure here?
>>
>> (gdb) disass/s ProtSet
>> Dump of assembler code for function ProtSet:
>>    0x0000556e0edcf8b0 <+0>:     push   %r12
>>    0x0000556e0edcf8b2 <+2>:     mov    %edx,%r12d
>>    0x0000556e0edcf8b5 <+5>:     push   %rbp
>>    0x0000556e0edcf8b6 <+6>:     mov    %rdi,%rbp
>
> Hmm.  You've compiled MPS without -fno-omit-frame-pointer.  I think
> (hope!)  that's safe as only references created outside of MPS can pin
> objects...

Sorry! Next build will use -fno-omit-frame-pointer. 

_________________________________________________________________
________________________________________________________
Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de






This bug report was last modified 162 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.