Re: Before 4.2.1 is finalized ...

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, 23 Jul 2004, Philippe Troin wrote:

> I'd be interested in the strace output of the problem shell.

In my original message, I reported:

	glibc-2.3.2-95.6
	gcc-3.2.3-24

I've since upgraded CentOS, so I now have:

	glibc-2.3.2-95.20
	gcc-3.2.3-34

Also the kernel changed from:

	kernel-smp-2.4.21-9.0.1.EL.c0

To:

	kernel-smp-2.4.21-15.0.3.EL.c0

I can no longer reproduce the problem with a freshly-compiled 4.2.x from 
CVS.  I *can* stil reproduce it with the 4.0.7 zsh binary that was 
originally installed from RPM (zsh-4.0.7-1).  I don't have an unpatched
copy of the 4.2.0 binary compiled with the old compiler/libraries, so I
can't make a comparison to that.

I diffed the strace output from the failing 4.0.7 and the working 4.2.x, 
and found that 4.0.7 *never* makes the ioctl(TIOCSPGRP) system call.  At 
first I thought this meant the failure return from tcsetpgrp() must be 
coming from glibc itself, but ltrace shows that even tcsetpgrp() is not 
called.  I can follow the trace through what must be the init_shout() call 
in init_io(), but it goes awry -- it's as if the 4.0.7 RPM were built with 
#undef JOB_CONTROL.  Yet I *was* having this identical problem with 4.2.0, 
previously, and I built that myself and I did see tcsetpgrp() called (and 
failing) when tracing through 4.2.0 with GDB.

Maybe the RPM builders knew tcsetpgrp() was unreliable and just compiled 
it out entirely, but that seems pretty strange, and there's no mention of
it in the RPM changelog.  (The SRPM is straight from RedHat.)

So perhaps this rates a mention in the MACHINES file, or perhaps not, but 
I guess no change for this is required.  The infinite loop I mentioned 
still bothers me, but I don't have a specific suggestion.