bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help debugging Re: bug report


From: Mathew Yeates
Subject: Re: Help debugging Re: bug report
Date: Wed, 27 Mar 2002 13:16:52 -0800

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]