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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Oliver Reiter <oliver.reiter <at> snapdragon.cc>
Cc: 75689-done <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#75689: 31.0.50; feature/igc: crash after calling 'mu4e'
Date: Sat, 22 Feb 2025 14:46:32 +0000

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

> "Oliver Reiter" <oliver.reiter <at> snapdragon.cc> writes:
>
>> 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
>
> Oh.  I guess I should have asked for (gdb) p *(struct Lisp_String *)0x7fffbe88c2c8
>
> Anyway, the data at 0x7fffe24599a8 is ASCII, starting, it seems, in the
> middle of a string, so the string was probably collected and its sdata
> area used for something else.
>
>>> x/32gx 0x7fffe245999a8
>
> Extra '9' there, sorry.
>
> Anyway, it seems very unlikely to me that this bug is still present in
> this form, so I'm closing the report.  Thank you very much for the
> report, and please do reopen or open new ones for further issues!
>
> Pip

Now without a typo.  Sorry for the noise.

Previous Next

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