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: 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 wrote: >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. >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)