On 22. Jun 2022, 15:39 +0200, Eli Zaretskii , wrote: > > Date: Wed, 22 Jun 2022 10:13:08 +0200 > > From: Gerd Möllmann > > Cc: 56108@debbugs.gnu.org > > > > On 20. Jun 2022, 21:10 +0200, Eli Zaretskii , wrote: > > > > I don't understand why some callers of compile_pattern mark the cache > > entry as busy, but some others don't. If a cache entry that is in use > > is not marked as busy, then any GC can decide to shrink the cache by > > freeing that entry. > > > > struct re_pattern_buffer *bufp; > > ... > > bufp = &compile_pattern (regexp, > > ... > > > > The address operator is there to confuse the Russians. > > > > Hmm... did you mean by that to explain why some callers of > > compile_pattern don't mark the new cache entry as "busy"? Because if > > so, I guess I'm one of the "confused Russians", as I don't understand > > the explanation. Please elaborate. > > Sorry, looking at this again, I'm now also completely confused. I see, all in search.c: static struct regexp_cache * compile_pattern (Lisp_Object pattern, struct re_registers *regp, and then, later struct re_pattern_buffer *bufp; bufp = &compile_pattern How the heck does this compile? > > > > Or maybe _I_ should elaborate. By "marking an entry busy" I meant the > > call to freeze_pattern, Yes, I've seen that. > > not a call to freeze_buffer_relocation (the > > latter is mostly a no-op nowadays, as almost all the supported > > platforms don't use ralloc.c). So it isn't the C pointer we keep > > around to compile_pattern's result that bothered me, it's the fact > > that the pattern cache entry created by compile_pattern is not > > protected from being freed by shrink_regexp_cache that is called by > > GC. AFAIU, that entry must be protected for the whole time the > > compiled pattern is in use by re_match_2 or any of its callers. > > > > Does the above make sense? Yes, it's the same I see. Functions fast_string_match_internal* don't freeze in the sense you explained.  What I don't see so far is what could lead to a GC in these cases, between the compile_pattern and the use of its result... Did you find other places where there's no freeze? Can Emacs GC while handling a signal? Does Emacs use threads nowadays?