If set the number of history saves is 0, assertions fail when inserting an entry on exit.
Dont insert an entry when the number of saves is 0 fixes the issue.
fixes#11497
Since 8b8ecf4, the shada module loads files in the jumplist to properly
clear duplicates. This can trigger some autocommands, which in turn
saves and restores search and substitute patterns, freeing the previous
strings in "spats" which are held in "wms" as well (heap-use-after-free).
To avoid this, initialize the jumplist in "wms" before search patterns.
- Always load files when cleaning up jumplist.
- For Shada: avoids writing duplicate entries, which happens when you read
from a shada file with duplicate entries (merging the jumplist while
writing sometimes produces duplicate entries, bug?) and then write right
away (i.e.: without any `:jumps`, `getjumplist()`, or any jump movement,
that is: nothing that calls `cleanup_jumplist` with `loadfiles == true`).
- For Context: avoids non-idempotent behavior for the same reason (i.e.:
first call to `shada_encode_jumps` does not remove duplicate entries).
- Do not set pcmark when dumping jumplist for Context.
- Retrieving current Context shouldn't add an entry to the jumplist
(which will be removed by a subsequent `cleanup_jumplist` anyway, i.e.:
tail entry matching current position), just act like `getjumplist` for
instance.
Problem: Terminal buffers are stored in the viminfo file while they can't
be useful.
Solution: Skip terminal buffers for file marks and buffer list
e62780543f
- Check shada_pack_xx() result, abort on failure.
- Use xcalloc() to zero-initialize `wms`, fixes below ASAN failure.
ASAN failure (running vim_spec.lua in a loop):
../src/nvim/shada.c:1773:13: runtime error: load of value 224, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/nvim/shada.c:1773:13
Adding an explicit check just before the ASAN failed line:
case kSDItemRegister: {
if (*((int *)(void *)&entry.data.reg.is_unnamed) != 1
&& *((int *)(void *)&entry.data.reg.is_unnamed) != 0) {
abort();
(gdb) p entry.data.reg
+p entry.data.reg
$5 = {name = 49 '1', type = kMTLineWise, contents = 0x60200000c250, is_unnamed = true, contents_size = 1, width = 0, additional_data = 0x0}
(gdb) p *((uint8_t *)(void *)&entry.data.reg.is_unnamed)
+p *((uint8_t *)(void *)&entry.data.reg.is_unnamed)
$7 = 2049
Nvim notes:
- Nvim does not support "-u DEFAULTS", that change is omitted.
- Also add 'shadafile' as an alias to 'viminfofile'.
- Deprecate 'viminfofile'.
Problem: Not easy to start Vim cleanly without changing the viminfo file.
Not possible to know whether the -i command line flag was used.
Solution: Add the --clean command line argument. Add the 'viminfofile'
option. Add "-u DEFAULTS".
c4da113ef9
Note about shada.c:
- shada_read_next_item_start was intentionally shadowing `unpacked` and
`i` because many of the macros (e.g. ADDITIONAL_KEY) implicitly
depended on those variable names.
- Macros were changed to parameterize `unpacked` (but not `i`). Macros
like CLEAR_GA_AND_ERROR_OUT do control-flow (goto), so any other
approach is messy.
Problems:
- In two places in shada_read_when_writing() memory just was not freed. Both
places were verified to cause test failures.
- Numbered marks got assigned incorrect (off-by-one compared to position in the
array) numbers in replace_numbered_mark.
- It was possible to have non-continuously populated array of numbered marks
which messed up code for merging them.
(Note about tests: marks with additional data are always compared different when
merging, that caused some confusion regarding why test did not work the way
I expected.)
Problems so far:
- Marks in the current instance are not adjusted.
- Duplicates are not removed (not that it works in Vim either now, not at
8.0.134 at least).
Although GCC now detects possibly unintentional fall through, there
rules around which the comments are detected are rather strict. In
cases where a comment isn't detected, upstream [recommends] using their
fallthrough attribute.
[recommends]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817#c11
