]> git.ipfire.org Git - thirdparty/vim.git/commit
patch 9.1.1387: memory leak when buflist_new() fails to reuse curbuf v9.1.1387
authorSean Dewar <6256228+seandewar@users.noreply.github.com>
Wed, 14 May 2025 18:16:52 +0000 (20:16 +0200)
committerChristian Brabandt <cb@256bit.org>
Wed, 14 May 2025 18:16:52 +0000 (20:16 +0200)
commit0077282c8209e5a3893d74a0176ab21895c5de4e
treecfe902de2c61d107de47f8475ca706fd3f7f834f
parentc952fd1b24fed70093009dbf53214431149a6d53
patch 9.1.1387: memory leak when buflist_new() fails to reuse curbuf

Problem:  buflist_new() leaks ffname and fails to reuse curbuf when
          autocommands from buf_freeall change curbuf. Plus, a new
          buffer is not allocated in this case, despite what the comment
          above claims.
Solution: Remove the condition so ffname is not leaked and so a new
          buffer is allocated like before v8.2.4791. It should not be
          possible for undo_ftplugin or buf_freeall autocommands to
          delete the buffer as they set b_locked, but to stay consistent
          with other uses of buf_freeall, guard against that anyway
          (Sean Dewar).

Note that buf is set to NULL if it was deleted to guard against the (rare)
possibility of messing up the "buf != curbuf" condition below if a new buffer
happens to be allocated at the same address.

closes: #17319

Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
src/buffer.c
src/testdir/test_autocmd.vim
src/version.c