[vim/vim] “E967 text property info corrupted”, with data loss, via coc/coc-rust-analyzer (Issue #9320)
Chris Morgan
Steps to reproduce
No steps to reproduce at present, but I’ve had “E967 text property info corrupted” pop up a few times in the past week or two, and just now it caused genuine data loss, so I figured I’d file something to see if I can get suggestions on how to diagnose further.
I presume that coc and coc-rust-analyzer are contributing to the error, for it occurs only when editing Rust source, and coc is the only thing I have that should be touching text properties.
I believe it’s linked to actions that remove lines, most significantly rewrapping text.
Just now the action that had data loss occur was I think joining a line: something like this:
struct Struct { pub field1: Type, pub field2: Type, /// Description // More internal-focused commentary // for some lines pub field3: Type, /// Description // More internal-focused commentary // for some lines⁑ // and finally the last line pub field4: Type, pub field5: Type, }
With the cursor at ⁑, the second last line of that bunch of comments.
Then I think I did gwj or similar, which should have joined “and finally the last line” onto the same line (I think it all fit). But instead, I got something like the first word of the next line (sorry, I’ve forgotten now and broken it further so I can’t find out what it was like), followed by ^E (U+0005), and E967, and I can’t undo back to what it was before, and if I make other edits (with E967 cropping up and being annoying regularly when it realises things are broken) and try to undo past the broken point it gets stuck again.
I think this was the first time this E967 has been kinda persistently broken, or caused data loss. In fact, I think this might be the first non-crash data loss I’ve had in over 15 years of heavy Vim use!
Expected behaviour
(Is this a trick question?)
Operating system
Arch Linux
Version of Vim
vim 8.2.3582, in Alacritty
Logs and stack traces
No response
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
lacygoill
I presume that coc and coc-rust-analyzer are contributing to the error, for it occurs only when editing Rust source, and coc is the only thing I have that should be touching text properties.
Unfortunately, I doubt any dev has the time to reduce the code of a plugin with 62523 lines of code, on top of the code of a plugin for another plugin with 2688 lines of code.
I can't undo back to what it was before
Not sure it helps, but have a look at :help g- and :help :earlier. In particular, :earlier 1f should return the buffer to how it was the last time it was written into a file.
I figured I'd file something to see if I can get suggestions on how to diagnose further.
Assuming that Vim crashes when this internal error is given, you might try to run a Vim with debugging symbols and enable the ABORT_ON_INTERNAL_ERROR option in src/Makefile:
make clean
make distclean
sed -i 's/#ABORT_CFLAGS = -DABORT_ON_INTERNAL_ERROR/ABORT_CFLAGS = -DABORT_ON_INTERNAL_ERROR/ ; s/#CFLAGS = -g$/CFLAGS = -g -O0/ ; s@#STRIP = /bin/true@STRIP = /bin/true@' src/Makefile
make
When the error is given, if Vim crashes, you could get a core file from which you could extract a backtrace, which in turn might help the devs fix the issue.
See also the wiki page about creating a gdb stack trace.
Bram Moolenaar
I'm afraid there is nothing I can do without reproduction steps. It's possible that splitting and joining lines is involved.
Dominique Pellé
E967 is an internal error:
textprop.c: iemsg(_("E967: text property info corrupted"));
So if you compile with -DABORT_ON_INTERNAL_ERROR Vim will abort which may make it easier to debug. There will then be a core dump and we can find the stack with gdb. It's only a matter of uncommenting this line in vim/src/Makefile:
ABORT_CFLAGS = -DABORT_ON_INTERNAL_ERROR
Consider also building Vim with asan (address sanitizer) in case it detects other memory errors prior to this crash (use after free, etc.). You can uncomment these lines in vim/src/Makefile:
SANITIZER_CFLAGS = -g -O0 -fsanitize-recover=all \
-fsanitize=address -fsanitize=undefined \
-fno-omit-frame-pointer
asan will make vim slower but it's nicer find and report bugs. asan will output errors (if any) on stderr so I sugges to run vim like this: vim 2> asan.log
paul-ollis
@chris-morgan. It is possible that #10431 has fixed this. Are you in a position to try Vim with this fix for a few weeks?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Chris Morgan
I haven’t experienced this since updating to a build that includes that patch, so it’s very probably fixed by that. Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Chris Morgan
Closed #9320 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.