On Aug 2, 2009, at 14:31, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov <kostikbel_at_gmail.com> wrote: >> I run a screen(1), where I tried to copy large portion of output and >> paste it into vi. This resulted in the loss of the characters at >> random >> points inside the pasted text. > > I already took some time to investigate the issue. I have attached a > patch that should already improve the situation: > > - write() on a pseudo-terminal master also accounted the data that was > read into the kernel, but couldn't be passed to the TTY (which is > likely to happen in non-blocking mode). > > - There was also a small unrelated issue; input on a TTY which has > been > configured in block (bypass) mode wouldn't set the input high water > mark. > > For some reason, the data loss doesn't occur when SSHing to myself > multiple times, but still causes screen(1) to drop some bytes later > on. > > Even though it's always very easy to blame other applications, I > suspect > this may be because I reduced the input buffer size from 8 KB to 2 KB > per pseudo-terminal. Maybe screen(1) can't deal with this. To be > investigated... Hmm, so I'm guessing this is the reason I've had trouble with copying/ pasting backtraces the last few days (I ssh into the box, which runs screen). I have, AFAIK, not noticed anything else than newlines dropping, though (I usually end up with lines such as "zfs_suspend_fs() at zfs_suspend_fs+0x2bzfs_ioc_recv() at zfs_ioc_recv +0x28b"). Also, do you know when this issue first appeared? I think I've been experiening this for more than a week or so, probably a lot longer (2-4 weeks? even longer)... could be sketchy memory, though. Regards, ThomasReceived on Sun Aug 02 2009 - 11:22:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC