Re: Help debugging Re: bug report

[David Kaelbling]

There are a bunch of environment variables you can set to customize
where groff looks for things.  They are documented in the man page.  In
this case I think you want to set GROFF_TMAC_PATH.

        David

Mathew Yeates wrote:
> 
> Ooops, sorry about that... I thought it was only being called once.
> Now I see the error.
> 
> gtroff is opening  /usr/lib/tmac/tmac.an instead of
> my tmac.an. I followed the instruction in PROBLEMS
> 
> > rest=`echo ${1+"$@"} | sed -e 's+/usr/lib/tmac+/usr/local/lib/groff/tmac+'`
> > exec groff -Wall -mtty-char $T $opts $rest
> 
> does something similar need to be done for gtroff?
> 
> > Is this from the first or second invocation of gtroff?  As I was trying
> > to explain in my previous message man will invoke the format command
> > twice: once with all the file descriptors closed just to see if it
> > exists, and a second time with them open to do the work.
> >
> >       David
> >
> > Mathew Yeates wrote:
> > >
> > > 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
> >
> > --
> > David KAELBLING <address@hidden>     Silicon Graphics Computer Systems
> > 1 Cabot Rd, suite 250; Hudson, MA 01749           781.839.2157, fax ...2357

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