www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/07/15:38:54

Date: Fri, 7 Apr 2000 11:06:48 -0400 (EDT)
Message-Id: <200004071506.LAA21108@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: pjfarley AT banet DOT net
CC: djgpp AT delorie DOT com
In-reply-to: <38ed4b38.5210950@news3.banet.net> (pjfarley@banet.net)
Subject: Re: Possible bash v2.03 file handle leak?
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000406132119 DOT 3003M-100000 AT is> <38ed4b38 DOT 5210950 AT news3 DOT banet DOT net>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> How can
> I set a breakpoint in a dynamically invoked program?  Isn't bash
> externally invoked from make?

Yes, it is.  However, from your description of the problem, I
understand that there's a single Bash invocation that uses up all the
available file handles.  So there's only one Bash invocation that
fails, and that is the invocation you should debug.

> Does that mean that I also have to
> build make with -g to get to the breakpoint that invokes bash?  Even
> if I invoke make from within a copy of bash started from gdb instead
> of from the DOS prompt, doesn't a second copy get loaded into memory
> by make?  How do I set a break in the second copy?

You can't: the DJGPP version of GDB doesn't support the `attach'
command, so you cannot attach the debugger to an already running
process.

Instead, you need to identify the command in the Makefile which
invokes Bash and fails due to the shortage of file handles, and edit
that command line so that it invokes Bash through GDB.

One way of doing that is as follows.  Assume that the offending
Makefile rule says something like this:

  foo: bar
	cd foobar && test.sh

Then you need to create a file gdb.ini in the directory where Make
runs, and put these three lines into that file:

      dir /path/to/bash/sources/
      break fatal_error
      run cd foobar && test.sh

(This assumes that the function where you want to put a breakpoint is
called fatal_error.)  It's possible that you will need to say this
instead:

      run "cd foobar && test.sh"

Then replace the rule in the Makefile with this:

  foo: bar
	gdb /path/to/bash.exe

This setup will run the offending test (and only the offending test)
under GDB.  When the breakpoint is hit, GDB will kick in and let you
do whatever you need.

> Also, since it is "sopen" reporting the error (this is a library
> function, isn't it?), doesn't that mean I have to link bash with a
> debugging copy of the library to get to that point?

I'm guessing that it's not `sopen' that reports the error, but rather
some other function that gets called when `sopen' fails.

In any case, there's no `sopen' in the DJGPP library.  So this
function's sources are somewhere in the Bash distribution.

> Or is it as simple as setting the SHELL variable to invoke gdb with
> bash as it's argument just before the failing test, inside the
> Makefile?

No, you cannot do that safely via setting SHELL.  You must edit the
Makefile.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019