Subject: bug#78943: feature/igc [PATCH] Trace current minor maps exactly

From: Pip Cet <[email-masked]>
Date: Sat, 12 Jul 2025 10:17:27 +0000

"Helmut Eller" <[email-masked]> writes:

> On Wed, Jul 09 2025, Pip Cet wrote:
>
> [...]
>> Thanks, LGTM.  Hope that applies to the other accumulated patches, too,
>> then I'll install them all.
>
> Thanks.
>
>> This is a preexisting bug, but I'm suspicious about the code leaking a
>> pointer to an igc_xzalloc'd area to its caller, which may call Lisp
>> (when it autoloads a map) in the case of Fminor_mode_key_binding.  If
>> that Lisp code recursively accesses keymaps and the maps get
>> reallocated, we end up resurrecting free'd data, and will probably
>> crash.  (My suspicion is this is the reason for the "don't use realloc"
>> comment, too).
>>
>> We should really fix this on master and just use vectors, and it's
>> probably even less effort for you to do so than it is for me, but I
>> still don't get how code like this is meant to be fixed.
>>
>> (I hope the comment about static being defined to the empty string is no
>> longer accurate :-) ).
>
> :-) That's a curious comment.  The overflow check in current_minor_maps
> is also curious.
>
> A simple fix for Fminor_mode_key_binding would be to copy the modes and
> maps arrays to an alloca'd area before calling Flookup_key.
>
> In the patch below (for master) I tried something different: remove the
> global variables cmm_maps and cmm_modes entirely.

Thanks.  It'd be nice to have a more general approach to growable
vectors, but in this case, I don't understand why we use array
structures at all: two simple linked lists should work just as well.

So I don't think a specific new structure for the cmm case is the right
approach here; it should be easy enough to generalize to vectors of
Lisp_Object, and the code would be cleaner without the "two vectors
placed back-to-back" assumption.

One place which would benefit from growable vectors is json.c.

My idea still would be to grow a vector aggressively until it's large
enough to fit all elements, then "truncate" it in place in such a way
that the GC knows to shrink it when it gets copied to the next
generation.

However, even that approach may be too complicated.

Pip