> Bram Moolenaar wrote:
>>
>> Gary Bickford wrote:
>>
>>
>>>
>>> I often misuse vim to view log files while debugging batch jobs. It is
>>> very handy for moving around in the file, viewing the colorized content
>>> and searching for relevant text. These log files can be from several
>>> thousand to millions of lines. Vim does a remarkably good job of
>>> handling these files. However, sometimes it has a problem when the
>>> batch job is re-run while I am viewing the file in vim, and the log file
>>> is replaced by a much shorter one.
>>>
>>> When vim tries to reload the file, sometimes I get a very long series of
>>> red warning messages - I can't repeat the event just now, so can't
>>> provide the content of the warning, but I think it has to do with
>>> missing lines.
>>>
>>> This succession of warnings can be inconvenient when there are several
>>> million to report, or even a few thousand! And very occasionally vim
>>> hangs (apparently), or just gives up the ghost and dies. I think
>>> problems are more likely when the 'present location' is far down the
>>> file.
>>>
>>> Considering the abuse I am giving vim this is within the range of
>>> acceptable behavior, but I thought it was worth mentioning as an issue
>>> anyway. From the behavior, I speculate that vim has found the present
>>> line to be after the end of file, is trying to move the line pointer
>>> upwards one line at a time, and is finding no data there each time.
>>>
>>
>> It would help a lot to know what the text of that error message is.
>>
>> If it is " ml_get: cannot find line {N}" then the cause might be hard to
>> find. A stack trace would be helpful then.
>>
>>
>
> That is the error message - E315 ml_get: cannot find line (N). I note that
> if I type 'q', when it waits for me to hit enter, I don't have to hit Enter
> after each line, it just spews this error message with increasing line
> numbers until it gets to the end or dies with a segfault.
>
> I am not at work so I can't run any tests today - sorry for the slow
> response cycle. Since I don't write C, I haven't had to deal with segfaults
> for a long time. To get a stack trace, do I need to run vim under gdb?
Hi
E315 error indicates an internal error according to ":help 315".
It's definitely worth reporting.
Which version of Vim are you using? Latest version is 7.2.377.
You can see the version with ":version".
Vim only loads the file at startup so even if the file is being changed
be another process while being edited in Vim, it should not matter I
would think. Do you remember what you were doing in Vim which
could trigger this bug? What plugins did you install?
Looking at ftp://ftp.vim.org/pub/vim/patches/7.2/README, I see
several recent patches which fixed E315 errors:
7.2.215 ml_get error when using ":vimgrep"
7.2.226 ml_get error after deleting the last line
7.2.375 ml_get errors when using ":bprevious" in a BufEnter autocmd
7.2.376 ml_get error when using SiSU syntax
So bug may have already been fixed. I would suggest to
download & compile the latest version of Vim if you can.
-- Dominique
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment