Re: bug report

[David Kaelbling]

Sorry, this doesn't ring any bells with me.  Can you send me the test
case?  I'll try building a debug version of groff (2.5?) and see if I
can find the close().

        David

Werner LEMBERG wrote:
> 
> [David, maybe you can help here.  I've noted that recently a similar
> problem has been discussed on the emacs-devel list, and maybe this
> problem is related.
> 
> Here the original report; Mathew is using an SGI Octane with Irix 6.5:
> 
>   Error: geqn fails when it tries to write output to stdout.  This
>   happens at line 378 of main.cc.  Doing a system call trace, it
>   appears that stdout has been closed.  I added a line of code to
>   print out the errno when the printf fails.  I get "stdout': Bad file
>   number"
> 
>   It appears that stdout was closed long before the error.  In the
>   trace I see "open" calls returning the value 1.
> 
> Does this sound familiar?]
> 
> > Something really strange.... my system trace shows that man closes
> > file descriptors 0,1, and 2 just prior to execv-ing nroff.  Maybe
> > the problem here is SGI's "man"??  I notice that when I run using
> > the sgi nroff, eqn does not write to stdout.  Instead, nothing is
> > written to stdout again until man does a "write" after calling
> > ioctl(1, __OLD_TCGETA, <bad indirect __old_termio param - len 30>)
> > OK
> >
> > Maybe it isnt safe to call printf from with eqn without checking
> > first that the IO file handles are still open??
> 
> AFAIK, stderr, stdin, and stdout are opened and closed automatically
> at the start and end of the program.  If nothing explicitly closes the
> handles, they should be always available.  There is some trickery to
> duplicate streams in groff.cc IIRC, but none is really closed.
> Anyway, this shouldn't affect eqn.
> 
>     Werner

-- 
David KAELBLING <address@hidden>            Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749     781.839.2157, fax ...2357