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