RE: serious subprocess output bug in 21.4, 21.5
Hi Ben and Stephen,
Good to hear from you both and thanks for forwarding that mail;
I left Alphatech about 4 years ago...
Anyway, I spent a bunch of time on this yesterday, but just as
I was about to send an email detailing all of that, absolutely
convinced it was xemacs' fault, I decided to do one more test
and have now absolved xemacs.
I can reproduce the problem from a shell as follows:
CVS_RSH=ssh /usr/bin/cvs diff <<file>> 2>&1
Some combination of CVS_RSH=ssh and combining cvs' stdout and
stderr together causes the problem. Of course the xemacs
process code defaults to combining the two streams.
The result is dramatic - if I run "find ." in a loop in another
window from my home directory while running cvs repeatedly, bytes
are almost always lost, and sometimes I only get 10% of the bytes.
Using the same cvs and ssh executables that work on my RH 6.2
box, I can still reproduce the problem on my RH 7.3 box.
Argh.
Anyway, thanks for your time and best wishes,
Greg
greg, it's not clear that finding a better reproduction scheme
would
help since this may be linux- or even red-hat-7.3-specific.
what *would* help is if you were willing to retrieve some old versions to try
and figure out when this happened. cvs lets you check out by date, and if you
could do a binary search by date -- even just a few iterations -- between the
21.4.6 release date and the 21.1 branch-off point to narrow down when the bug
appeared, it would be a *huge* help.
ben