diff options
| author | Sean Dewar <6256228+seandewar@users.noreply.github.com> | 2025-05-14 19:39:13 +0100 |
|---|---|---|
| committer | Sean Dewar <6256228+seandewar@users.noreply.github.com> | 2025-05-15 08:47:49 +0100 |
| commit | 6b9665a507b16182a6d5c4e45518517b3547b48e (patch) | |
| tree | 06a41730d61ddb1b2eb1fdf207329d47d7a2bdb2 /runtime/lua/vim/provider/python.lua | |
| parent | f2aec4bc0579e94b0f0ed5e5524a05c71ffb393e (diff) | |
| download | rneovim-6b9665a507b16182a6d5c4e45518517b3547b48e.tar.gz rneovim-6b9665a507b16182a6d5c4e45518517b3547b48e.tar.bz2 rneovim-6b9665a507b16182a6d5c4e45518517b3547b48e.zip | |
vim-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: vim/vim#17319
https://github.com/vim/vim/commit/0077282c8209e5a3893d74a0176ab21895c5de4e
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Diffstat (limited to 'runtime/lua/vim/provider/python.lua')
0 files changed, 0 insertions, 0 deletions