Re: Help debugging Re: bug report

[Mathew Yeates]

Okay, this is all I've been able to figure out. I'm getting an error in
real_output_file::~real_output_file() of node.cc of gtroff. Line 1519.
I inserted a perror and got "No such file or directory".

Here is a bit of the system strace. Notice that file descriptors 0,1,2
appear to be have been detached from stdin,stdout and stderr. My guess
(and its only a guess), is that because 0,1,2 have been closed by sgi's man,
when gtroff tries to printf or puts, it fails.

Mathew


 144mS[  7]          gtroff(5017124): read(1, ".\" final startup file for tro",
 4096) = 694
  145mS[  7]          gtroff(5017124): read(1, 0x10104788, 4096) = 0
  145mS[  7]          gtroff(5017124): close(1) OK
  145mS[  7]          gtroff(5017124): ioctl(0, __OLD_TCGETA, 0x7fff2a10) errno
= 25 (Inappropriate I/O control operation)
  145mS[  7]          gtroff(5017124): read(0, "\n# eof\n", 4096) = 7
  145mS[  7]          gtroff(5017124): read(0, 0xfb5d110, 4096) = 0
  146mS[  7]          gtroff(5017124): write(2, "gtroff: fatal error: ", 21) 
err
no = 9 (Bad file number)
  146mS[  7]          gtroff(5017124): write(2, "error writing output fil"
, 32) errno = 9 (Bad file number)
  146mS[  7]          gtroff(5017124): prctl(PR_LASTSHEXIT) = 1
  146mS[  7]          gtroff(5017124): write(1, "x T ascii\nx res 240 24 40\nx 
i
n", 104) errno = 9 (Bad file number)
  146mS[  7]                (5018038): was sent signal SIGCLD
  146mS[  7]          gtroff(5017124): exit(1)





> I looked through the source for man.  It closes fd's 0,1,2 before doing
> an exec in the specific case where it is testing to see if a filter
> exists.  (It's in "forkandexeclp", if you have some similar source to
> browse.)  This invocation is expected to die.
> 
> Later on man will fork() again and use system() to actually run the
> filter.  You can use "man -p" to see what commands it would run.
> 
>       David
> 
> Mathew Yeates wrote:
> > 
> > I'm tryin to debug groff running on SGI Irix 6.5.
> > 
> > When I do a system trace on man I see that file descriptors 0,1,2 are
> > closed by make immediately prior to gnroff being forked. Is this correct
> > behavior? I tried adding the line "echo HELLO" near the beginning of
> > gnroff and, as expected, this fails with a "bad file descriptor" message
> > in my trace.
> > 
> > Does that happen with other OS's?
> 
> -- 
> David KAELBLING <address@hidden>          Silicon Graphics Computer Systems
> 1 Cabot Rd, suite 250; Hudson, MA 01749           781.839.2157, fax ...2357