bug#56623: memory leak introduced by new nonrecursive lisp reader

[Lars Ingebrigtsen <larsi@gnus.org>]

Mattias Engdegård <mattiase@acm.org> writes:

> A counter-argument is that these undead objects will only be kept artificially alive as long as GC only takes place in the reader. Anyway, the hunch is easily tested: try either or both of these changes:
>
> 1. reduce stackbufsize:
>
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -2919,7 +2919,7 @@ digit_to_number (int character, int base)
>  /* Size of the fixed-size buffer used during reading.
>     It should be at least big enough for `invalid_radix_integer' but
>     can usefully be much bigger than that.  */
> -enum { stackbufsize = 1024 };
> +enum { stackbufsize = 64 };
>
>  static void
>  invalid_radix_integer (EMACS_INT radix, char stackbuf[VLA_ELEMS (stackbufsize)],
>
> 2. zero the buffer on entry:
>
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -3678,6 +3678,7 @@ read_stack_push (struct read_stack_entry e)
>  read0 (Lisp_Object readcharfun, bool locate_syms)
>  {
>    char stackbuf[stackbufsize];
> +  memset (stackbuf, 0, stackbufsize);
>    char *read_buffer = stackbuf;
>    ptrdiff_t read_buffer_size = sizeof stackbuf;
>    char *heapbuf = NULL;
>
> If either makes things better, maybe we can come up with a solution that doesn't hurt performance.

This was a month ago -- Tom, did you try these changes?