Re: weird egcs bug

[Greg Bacon <gbacon at itsc dot uah dot edu>]

In message <Pine.LNX.4.04.10003160132550.31076-100000@inet-gw0.labs.ekto.org>,
    Mo McKinlay writes:

: # read_words(pid_t k1, int fd1, pid_t k2, int fd2)
: # {
: 
: [snip]
: 
: # If I uncomment the printf line, control exits the loop as expected.
: # Without it, however, the program hangs.  When I run it in the
: # debugger, b read_words, run, c, I don't see the behavior!  When I just
: # run the code and interrupt it, I see
: # 
: #     Program received signal SIGINT, Interrupt.
: #     0x400c19ee in __select ()
: #     (gdb) where
: #     #0  0x400c19ee in __select ()
: #     #1  0x0 in ?? ()
: #     (gdb) 
: 
: Is either fd1 or fd2 stdout? If so, printf() will write to them, and the
: select call will time out.

No.  They're the read ends of two pipes to two separate child processes.

:                            What happens if you add a timeout to your
: select() call (5 seconds or so), and check if it timed out? If my
: suspicions are correct, your program will wait 5 seconds then report that
: the timeout expired.

I tried that too, but the results were still the same.

: >From what I can tell, printf() is directly or indirectly touching fd1 or
: fd2, causing select() to return. When you remove the printf(), fd1 and fd2
: never get touched, so select() blocks indefinitely.

What's even weirder is that a printf() will cause the loop to exit, but
if I replace printf(...) with fprintf(stdout, ...), the program hangs.

: This is about as much as I can can glean from the fragment, and I could be
: wrong ;-) Experiment with the select() call, and see what happens.

I've tried everything I can think of.  SGI's compiler (please don't
think that I'm holding it up as a standard of excellence :-) builds
an executable that doesn't hang.  egcs-2.91.66 on Solaris 2.7 builds
an executable that doesn't hang.

Thanks for the suggestions.

Greg