[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56623: memory leak introduced by new nonrecursive lisp reader
From: |
Lars Ingebrigtsen |
Subject: |
bug#56623: memory leak introduced by new nonrecursive lisp reader |
Date: |
Sat, 27 Aug 2022 17:35:37 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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?
- bug#56623: memory leak introduced by new nonrecursive lisp reader,
Lars Ingebrigtsen <=