Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 52757
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: brookepb [...] mchsi.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in:
  • 1.25
  • 1.25-withoutworldwriteables
  • 1.25_brokentar
  • 1.26



Subject: File descriptor leak with DBD-Oracle
Date: Mon, 14 Dec 2009 09:12:00 -0600 (CST)
To: bug-DBD-Oracle [...] rt.cpan.org
From: brookepb [...] mchsi.com
Description: There appears to be a file descriptor leak for every oracle connection (even when using ora_dbh_share) when using DBD-Oracle in perl scripts using threads, threads::shared. To recreate the problem: 1) at start of a minimal perl script, using the libs noted above along with DBD::Oracle. print STDERR "Pre oracle connection open files:" . `ls -l /proc/$$/fd/ | wc -l` . "\n"; 2) open a new database connection 3) check open file descriptor count print STDERR "open oracle connection open files:" . `ls -l /proc/$$/fd/ | wc -l` . "\n"; 3) disconnect the connection print STDERR "Post oracle connection open files:" . `ls -l /proc/$$/fd/ | wc -l` . "\n"; One file descriptor remains open, at least on my machine after every call. In a single threaded application this is not an issue but in one that spawns thousands of threads which use Oracle, the maximum number of open filehandles available to the user account running the program is quickly exceeded and it is unable to complete. I had hoped that using ora_dbh_share would solve the problem but no beans. System: Linux myhost 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:58:24 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Perl: 5.10.0 DBD-Oracle: $DBD::Oracle::VERSION = '1.23'; I apologize if I missed this bug in those listed on CPAN Thanks, bpb
On Mon Dec 14 10:42:52 2009, brookepb@mchsi.com wrote: Show quoted text
> Description: > There appears to be a file descriptor leak for every oracle connection > (even when using ora_dbh_share) when using DBD-Oracle in perl > scripts using threads, threads::shared. > > To recreate the problem: > 1) at start of a minimal perl script, using the libs noted above along > with DBD::Oracle. > print STDERR "Pre oracle connection open files:" . `ls -l /proc/$$/fd/ > | wc -l` . "\n"; > 2) open a new database connection > 3) check open file descriptor count > print STDERR "open oracle connection open files:" . `ls -l > /proc/$$/fd/ | wc -l` . "\n"; > 3) disconnect the connection > print STDERR "Post oracle connection open files:" . `ls -l > /proc/$$/fd/ | wc -l` . "\n"; > > One file descriptor remains open, at least on my machine after every > call. In a single threaded application this is not an issue but in > one that spawns thousands of threads which use Oracle, the maximum > number of open filehandles available to the user account running > the program is quickly exceeded and it is unable to complete. I > had hoped that using ora_dbh_share would solve the problem but no > beans. > > System: > Linux myhost 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:58:24 EST 2009 > x86_64 x86_64 x86_64 GNU/Linux > Perl: 5.10.0 > DBD-Oracle: $DBD::Oracle::VERSION = '1.23'; > > I apologize if I missed this bug in those listed on CPAN > > Thanks, > > bpb
I don't see any fd leaks here. Since you are on Linux it would be nice to find out what this file descriptor is. You can something like this: valgrind --track-fds=yes perl myscript.pl where myscript.pl prints out $$ (PID), connects and sleeps for say 60s. in another terminal run sudo lsof > lsof.out after the connection. Now when the program exits valgrind should show you the leaked fds and you can compare those to what lsof says by looking for the fds open for the pid you printed and we should find out which file or socket is open. You may not have lsof and valgrind installed already. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #52757] File descriptor leak with DBD-Oracle
Date: Thu, 8 Apr 2010 12:29:42 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Brooke Peterson-Burch <brookepb [...] gmail.com>
Martin, I apologize for having to run my tests on an active work system where I do not have administrative rights so its not all that you hoped for. I couldn't run lsof as a super user but it and valgrind were present on the system. I've attached the valgrind and lsof output as separate files and below I show the file descriptor counts as described in the original bug listing. Test output to give you a feel for what I tried: valgrind --track-fds=yes ./TstOpenFileDescriptorIssue.pl 2> valgrind_op.txt #Test opening and closing connections 5 times w/out starting a thread Pre test open files:10 Post test open files:11 #All thread creation tests create and join 1 threads each. #Test thread creation with no open oracle connections Pre test open files:11 Post test open files:11 #Test opening and closing an oracle connection in each thread Pre test open files:11 Post test open files:12 #Test having an open oracle connection before creating threads which do not open additional connections. Pre test open files:12 Post test open files:14 #Test combination of an open oracle connect, and having each thread open and close a connection Pre test open files:12 Post test open files:15 Check lsof now! Final settled open files before terminating script:13 Completed testing Show quoted text
----- Original Message ----- From: "Martin J Evans via RT" <bug-DBD-Oracle@rt.cpan.org> To: brookepb@mchsi.com Sent: Thursday, April 8, 2010 2:34:56 AM GMT -06:00 US/Canada Central Subject: [rt.cpan.org #52757] File descriptor leak with DBD-Oracle <URL: https://rt.cpan.org/Ticket/Display.html?id=52757 > On Mon Dec 14 10:42:52 2009, brookepb@mchsi.com wrote:
> Description: > There appears to be a file descriptor leak for every oracle connection > (even when using ora_dbh_share) when using DBD-Oracle in perl > scripts using threads, threads::shared. > > To recreate the problem: > 1) at start of a minimal perl script, using the libs noted above along > with DBD::Oracle. > print STDERR "Pre oracle connection open files:" . `ls -l /proc/$$/fd/ > | wc -l` . "\n"; > 2) open a new database connection > 3) check open file descriptor count > print STDERR "open oracle connection open files:" . `ls -l > /proc/$$/fd/ | wc -l` . "\n"; > 3) disconnect the connection > print STDERR "Post oracle connection open files:" . `ls -l > /proc/$$/fd/ | wc -l` . "\n"; > > One file descriptor remains open, at least on my machine after every > call. In a single threaded application this is not an issue but in > one that spawns thousands of threads which use Oracle, the maximum > number of open filehandles available to the user account running > the program is quickly exceeded and it is unable to complete. I > had hoped that using ora_dbh_share would solve the problem but no > beans. > > System: > Linux myhost 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:58:24 EST 2009 > x86_64 x86_64 x86_64 GNU/Linux > Perl: 5.10.0 > DBD-Oracle: $DBD::Oracle::VERSION = '1.23'; > > I apologize if I missed this bug in those listed on CPAN > > Thanks, > > bpb
I don't see any fd leaks here. Since you are on Linux it would be nice to find out what this file descriptor is. You can something like this: valgrind --track-fds=yes perl myscript.pl where myscript.pl prints out $$ (PID), connects and sleeps for say 60s. in another terminal run sudo lsof > lsof.out after the connection. Now when the program exits valgrind should show you the leaked fds and you can compare those to what lsof says by looking for the fds open for the pid you printed and we should find out which file or socket is open. You may not have lsof and valgrind installed already. Martin -- Martin J. Evans Wetherby, UK

Message body is not shown because sender requested not to inline it.

Download lsof.out
application/octet-stream 27.1k

Message body not shown because it is not plain text.

I believe the latest 'trunk' version of DBD::Oracle have fixed this please give this code base a try http://svn.perl.org/modules/dbd-oracle/trunk and see if that fixes your problem.