GNU bug report logs - #75689
31.0.50; feature/igc: crash after calling 'mu4e'

Previous Next

Full log

View this message in rfc822 format

From: Oliver Reiter <oliver.reiter <at> snapdragon.cc>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 75689 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#75689: 31.0.50; feature/igc: crash after calling 'mu4e'
Date: Mon, 10 Feb 2025 22:56:23 +0100

[Message part 1 (text/plain, inline)]

Pip Cet <pipcet <at> protonmail.com> writes:

> "Oliver Reiter" <oliver.reiter <at> snapdragon.cc> writes:
>
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>
>>> tags 75689 + moreinfo
>>> thanks
>>>
>>> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
>>> editors" <bug-gnu-emacs <at> gnu.org> writes:
>>>
>>>> This bug report never made it into my inbox, so I only discovered it on
>>>> debbugs just now.
>>>
>>> (I also didn't get it.)
>>>
>>
>> Did you see bug#75760? There a crash happened during
>> redisplay_internal(), which I thought would be a more interesting
>> case.
>>
>>>> I'm not sure I can do much without a "bt full" backtrace in this
>>>> situation (and it's probably too late for that :-) ).
>>>
>>> I'm tagging this as moreinfo, to indicate that we need more information
>>> to do much here.
>>>
>>> Oliver, can you reproduce this?  If so, any chance you can produce a
>>> full backtrace?
>>
>> I cannot reproduce it "from scratch", but I have the coredump and the
>> binary and can generate the 'bt full':
>>
>> (Aside question: The source files mentioned below are at a newer
>> revision, should I have checked out the revision with which emacs was
>> built before calling 'bt full'?)
>
> I think it's sufficient to indicate the git commit in the bug report, we
> can then check out that commit to look at the precise same source code.
>
>> (gdb) bt full
>> #15 0x000055555579ca43 in fix_string (ss=ss <at> entry=0x7fffffffacb8, s=s <at> entry=0x7fffbe88c2c8) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1754
>>         res = <optimized out>
>>         ptr = 0x7fffe24599a8
>>         res = <optimized out>
>>         _ss = 0x7fffffffacb8
>>         _mps_zs = <optimized out>
>>         _mps_ufs = 9079819798744924160
>>         _mps_wt = <optimized out>
>>         _mps_w = <optimized out>
>
> Can you (after launching gdb with the right executable and coredump
> file) print the output of
>
> p *(struct Lisp_String *)0x7fffe24599a8
>
> That should let us know whether the string metadata looks like it's
> potentially valid still; if it doesn't, it's likely the string itself
> was lost due to another bug, possibly the specpdl resizing bug which has
> been fixed.  It may be best to close that bug report in this case, as
> we might be hunting a bug we've already found.
>
> However, even if the string metadata does look valid, its data pointer
> certainly wasn't....
>

Here you go:

(gdb) p *(struct Lisp_String *)0x7fffe24599a8
$1 = {gc_header = {v = 7593965280773943342, gcaligned = 46 '.'}, u = {s = {size = 7292582808427585908,
      size_byte = 8386654083790889773, intervals = 0x636c652e73,
      data = 0xd4a809b1d <error: Cannot access memory at address 0xd4a809b1d>},
    next = 0x6534756d2f726174, gcaligned = 116 't'}}

> Can you also produce the output of
>
> x/32gx 0x7fffe245999a8

(gdb) x/32gx 0x7fffe245999a8
0x7fffe245999a8:	Cannot access memory at address 0x7fffe245999a8

Previous Next

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