Subject: Re: 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

From: Pip Cet <[email-masked]>
Date: Thu, 09 Jan 2025 14:47:43 +0000

Gerd Möllmann <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> writes:
>
>>> Date: Thu, 09 Jan 2025 12:19:26 +0100
>>> From:  Gregor Zattler via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <[email-masked]>
>>>
>>> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>>> 432	{
>>> #0  terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde
>>> "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h",
>>> line=line@entry=597) at ./src/alloc.c:8377
>>> #2  0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
>>> , ch=32) at ./src/character.h:597
>>> #3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0
>>> <searchbufs+2912>, bufp@entry=0x5eb92b3c6c43c900, string1=0x0,
>>> string1@entry=0x555557025101 "\377\377\377\377\377\377\377\001",
>>> size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode:
>>> nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP:
>>> odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO:
>>> TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674,
>>> size2@entry=93825020464468, pos=43986, regs=<optimized out>,
>>> stop=<optimized out>) at ./src/regex-emacs.c:4553
>>
>> bufp->translate is not protected from GC?
>
> Thanks!
>
> I think the bufp should come from a regexp_cache entry that looking_at_1
> gets from compile_pattern, and passes to re_match_2
>
>   i = re_match_2 (&cache_entry->buf, (char *) p1, s1, (char *) p2, s2,
>
> compile_pattern chooses an entry from searchbuf_head, fills it out and
> so on. I think searchbuf_head refers to entries in searchbuf, which is
> an array of regexp_cache. And in syms_of_search we have
>
>   for (int i = 0; i < REGEXP_CACHE_SIZE; ++i)
>     {
>       staticpro (&searchbufs[i].regexp);
>       staticpro (&searchbufs[i].f_whitespace_regexp);
>       staticpro (&searchbufs[i].syntax_table);
>     }
>
> That doesn't look sufficient, at least for igc, don't know about the old
> gc. I'll see what must be added there, bufp->translate is certainly
> among that, but maybe there are others.

Thanks!  I agree with the analysis; I think it's safe for the old GC
because the table is traced through the buffer structure.

However, I don't think this is the bug we saw here: that we aborted in
backtrace_function () while trying to print a backtrace means something
very weird must have been happening to the specpdl: we verified
backtrace_p beforehand, and got the pointer from backtrace_top, so
unless the specpdl pointed to the very stack frame that was used by GDB,
what could explain this?

Gregor, can you run "print specpdl_ptr",
"print *(struct Lisp_String *)0x555557040d50", and "bt full"?

Thanks!
Pip