Re: serious subprocess output bug in 21.4, 21.5

>>>> Greg Klanderman <gak(a)klanderman.net&gt; writes:

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 >