Pip Cet <pipcet@protonmail.com> writes:

> "Oliver Reiter" <oliver.reiter@snapdragon.cc> writes:
>
>> Stefan Kangas <stefankangas@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@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@entry=0x7fffffffacb8, s=s@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