[sf-perl] Bad file number

[Loo, Peter # PHX]

Thanks again Steve.  I was going crazy looking for any clues that would
lead to the reason why I would get this error message.  I walked through
the logic to make sure that there is one close() for every open() and
also checked the result of both.  It turns out that the ODBC driver that
I am using for Netezza database is opening the odbc.ini file 7 times for
every connect to the database and is not closing the file.  I wrote a
simple program to loop through and connect and disconnect from the
database and watched my PID using lsof and learn that each connection
added 7 file handles for odbc.ini file.  It continued until it reached
the threshold of 256 file handles.  I wanted to look through the code to
the ODBC driver, but because it is compiled and was given to us by the
vendor, we have opened a ticket with them.

Thanks for all your help.  Have a nice weekend.
 
Peter

-----Original Message-----
From: sanfrancisco-pm-bounces+peter.loo=source.wolterskluwer.com at pm.org
[mailto:sanfrancisco-pm-bounces+peter.loo=source.wolterskluwer.com at pm.or
g] On Behalf Of Steve Fink
Sent: Thursday, June 21, 2007 9:46 PM
To: San Francisco Perl Mongers User Group
Subject: Re: [sf-perl] Bad file number

On 6/21/07, Quinn Weaver <quinn at fairpath.com> wrote:
> On Thu, Jun 21, 2007 at 02:30:40PM -0700, Loo, Peter # PHX wrote:
> > I have checked the logic and it appears that there is a 
> > corresponding close() for every open().  I don't know why Perl is 
> > warning me with this error.
>
> Just "checking the logic" by looking at your code doesn't cut it.
> You need to test empirically whether your code is doing what you think
it is.
>
> Try putting warn "closed file MYFILE successfully" after your close 
> statements... just to verify that what you think is happening is 
> actually happening.
>
> Make a habit of testing your assumptions this way.  It is the royal 
> road to figuring out bugs.  Debugging is a matter of practice, not 
> theory-- because if the code were working the way that you think in 
> theory it should be, you wouldn't have a bug!

Good general advice, but I'm not sure how well it applies in this
situation. How many ways can close() fail in such a way that the file
descriptor is not closed? If it did, what would the user be able to do
about it? (There are many ways for close() to fail, as many as there are
ways that write() can fail, but close() should still close the
fd.)

There *is* actually one way, if close() returned EINTR, but I doubt
that's what is happening here. I'm guessing the logic isn't quite right.
Checking the result of close() may indeed point out valuable clues,
though. (eg if it is returning EINVAL, perhaps you're not closing what
you think.) _______________________________________________
SanFrancisco-pm mailing list
SanFrancisco-pm at pm.org
http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


This E-mail message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information.  Any unauthorized
review, use, disclosure or distribution is prohibited.  If you are not
the intended recipient, please contact the sender by reply E-mail, and
destroy all copies of the original message.