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

Previous Next

Full log

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

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

"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....

Can you also produce the output of

x/32gx 0x7fffe245999a8

?

Thanks!

Pip

Previous Next

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