bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

"Gregor Zattler via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs@gnu.org> writes:

> Hi Pip,
> * Pip Cet <pipcet@protonmail.com> [2025-01-09; 19:27 GMT]:
> [... 29 Zeilen deleted ...]

Sorry about that; I tried to leave in enough context for my response to
make sense without having to reread the original report.

>> "deadl", which appears at the beginning of an Emacs string ("deadline") only in
>> org-agenda.el.  The string is unlikely to start earlier because the next
>> byte would be 0x08, an ASCII backspace.  Unlikely.
>>
>> More likely it's an unaligned string.  I think Emacs string data is
>> always aligned, except for pure strings.  But on scratch/igc, even pure
>> strings are aligned to an 8-byte boundary!
>>
>> "closed" also appears in org-agenda.el, but this string isn't
>> NUL-terminated: it's a Pascal-style string, with a length byte (0x06)
>> followed by 6 ASCII characters.  That would match the 8-byte "deadline"
>> literal.
>>
>> Possibly a (basic) compression format, probably lz4 or zlib.  I'm
>> guessing this is a git object, which is stored in zlib format, and that
>> appears to use length-prefixed string literals like these.
>>
>> What is it doing in your Emacs data?
>
> I have no idea.  If I remember
> correctly, I started Emacs and told it
> to load the org-agenda files, and that
> would be it, these are plain text.

Very strange.  We sometimes store .el/.elc files in gzipped form, but
.gz files don't usually contain literal strings contained in the
original (M-x find-file-literally seems to confirm this).

We can see some of your org agenda in the backtrace, so that shouldn't
be it.

> (gdb) p $rsp
> $10 = (void *) 0x7fffffff95f8

Nowhere near the corrupt data.  Again, very strange.

Pip