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

[GNU bug Tracking System]

Your message dated Mon, 29 Aug 2022 17:52:39 +0200
with message-id <DA3134F4-A648-4424-84FA-0977A1233AD0@acm.org>
and subject line Re: bug#56623: memory leak introduced by new nonrecursive lisp 
reader
has caused the debbugs.gnu.org bug report #56623,
regarding memory leak introduced by new nonrecursive lisp reader
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
56623: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56623
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: memory leak introduced by new nonrecursive lisp reader Date: Sun, 17 Jul 2022 15:03:16 -0700

While tracking down a memory leak in racket-mode git bisect
landed on b903507b36c438653a02d7b6291e9744d5221e28
Nonrecursive Lisp reader (bug#55676).

I do not have a minimal reproduction at the moment, but a
non-minimal one is documented at
see https://github.com/greghendershott/racket-mode/issues/632.
There are before and after graphs showing the change in behavior in
https://github.com/greghendershott/racket-mode/issues/632#issuecomment-1186609580

I have also attached the bisect script, and elisp needed to
reproduce the issue. Setting up the racket environment
to cause the issue is more involved (see the github issue).

Based on the behavior, it seems like strings and conses may be
marked by mark_lread but then somehow never unmarked, so
they never get collected, but that is a blind guess and I have no
idea if that is related at all.

ow.el
Description: Text Data

emacs-memory-leak-test.el
Description: Text Data

bisect-memory.sh
Description: application/shellscript

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#56623: memory leak introduced by new nonrecursive lisp reader
>
>
>
>
> Date: 
>
> Mon, 29 Aug 2022 17:52:39 +0200
>
>
>
>
> >> The new `read' leaks when it errors.
> > 
> > Looks like a very very silly mistake.
>
> Indeed it was (sorry!), and it should be fixed by c0bb1aac10.
> Many thanks for helping out!
>
>
>
>
> --- End Message ---