GNU bug report logs - #78943
feature/igc [PATCH] Trace current minor maps exactly

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 78943 <at> debbugs.gnu.org
Subject: bug#78943: feature/igc [PATCH] Trace current minor maps exactly
Date: Sat, 12 Jul 2025 10:17:27 +0000

"Helmut Eller" <eller.helmut <at> gmail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.