delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/07/15:05:27

From: pjfarley AT banet DOT net (Peter J. Farley III)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Possible bash v2.03 file handle leak?
Date: Fri, 07 Apr 2000 03:13:22 GMT
Message-ID: <38ed4b38.5210950@news3.banet.net>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000406132119 DOT 3003M-100000 AT is>
X-Newsreader: Forte Free Agent 1.21/32.243
NNTP-Posting-Host: 129.37.54.234
X-Trace: 7 Apr 2000 03:11:42 GMT, 129.37.54.234
Organization: Global Network Services - Remote Access Mail & News Services
Lines: 63
X-Complaints-To: abuse AT prserv DOT net
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
<Snipped>
>This doesn't prove that Bash has a bug.  It might well be that the test 
>uses up all the file handles on your system, and the earlier Bash 
>succeeds because it uses less handles in its routine operation.

Hmm-m-m.  I guess you're right about that.  And since the symptoms are
not consistant, I haven't really found anything, yet.

>To dig into this, I'd suggest to run the test suite under GDB.  That is, 
>download Bash sources, build it with -g and without -s, and then run it
>from GDB and invoke the script(s).
>
>Once you have this setup working, you need first to verify that the 
>problem doesn't disappear when you run from GDB. ;-)

Understood.  Many's the debugging session that makes the problem
disappear.  I call it "mechanic's syndrome" -- get your auto anywhere
within one-quarter mile of a really good mechanic, and all problems
seem to disappear...:)

>With that out of your way, put a breakpoint inside the function which 
>reports the error you see when the script fails.  When the breakpoint is 
>hit, examine the file handles open by Bash, e.g., by calling fflush for 
>each handle from GDB's command line.  Handles which return 0 are still 
>open, those which return -1 are not.  This will tell you how many handles 
>does Bash have open.  You want to prove that it has all 254 of them used 
>up.

I don't know gdb at all, so please excuse my ignorance here.  How can
I set a breakpoint in a dynamically invoked program?  Isn't bash
externally invoked from make?  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?

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?

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?

Advice and specific instructions on how to accomplish setting the
breakpoint would be greatly appreciated.

<Snipped>
>It might be useful to write a simple program to verify that claim (I 
>suspect that quite a few of the handle are taken up by Windows).  I 
>suggest to read section 9.7 of the FAQ for some insight, *before* you 
>write the test program.

I will read the FAQ, as you suggest.  I am curious to see how much (if
any) of the "default" claim is true.

I'll report back when I've got something more solid.  Thanks for the
assistance.

----------------------------------------------------
Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR
                     pjfarley AT nospam DOT banet DOT net)

- Raw text -


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