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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
