You can't spell "evil" without "vi".
Rob Landley
rob at landley.net
Tue Oct 14 08:48:54 UTC 2008
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.)
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.) The downside is that when you hit
escape with nothing after it, the gui won't update for 1/3 of a second, but
that's way better than corrupting data.
Rob
More information about the busybox
mailing list