You can't spell "evil" without "vi".

[Denys Vlasenko]

On Tuesday 14 October 2008 10:48:54 am Rob Landley wrote:
> On Sunday 12 October 2008 23:48:22 Rob Landley wrote:
> > Next time it reads a buffer, it starts with the last character of a cursor
> > left sequence: capital D.  Capital D is "delete to end of line", which it
> > does.
> >
> > So basically, busybox vi is corrupting your data when you cursor around in
> > a file on a loaded system.  Wheee...
> 
> Hmmm...  I redid the readit() code to only read ahead when processing an 
> escape sequence.  (This let me shrink the readahead buffer to 8 bytes, 
> actually 5 but with 32 bit alignment 8 makes more sense.  Bloatcheck says I 
> shrunk the code by 17 bytes.)

Disregard my previous patch, I just looked at your code and it's
as good but it's smaller than mine, so let's use yours.

> Unfortunately, this mitigated the problem a bit, but didn't actually _fix_ it.  
> It happens less often, but I can still trigger it.
> 
> I _think_ this is actually a qemu issue.  The escape sequences are being 
> generated by the host Linux, which are then sent to the qemu process over a 
> virtual serial console, which breaks them down into individual bytes with an 
> interrupt for each.
> 
> This means that the blocking we're depending on to parse escape sequences 
> doesn't work over a serial console.  You _can get an escape character by 
> itself with poll saying there's no more data, and then on the next clock 
> cycle you can get a "[D".
> 
> Hmmm...
> 
> Ok, making poll wait 300 miliseconds before deciding there's no next character 
> in a pending escape sequence seems to have fixed it.  (At least I can't 
> reproduce the problem under qemu anymore.)

Please document this next time, or someone else might come later
and delete the timeout. I did this a few mins ago :( will fix it now.

Did you try something smaller than 300ms?
--
vda