RE: FW: memory leak in DBI ...
It certainly does appear to leak memory for you, too. My script is similar, as
are my results.
Thanks for checking.
Appears to be a confirmed memory leak to me. Does anyone have an idea of how
the weakref code can be fixed to solve this? It appears that Tim doesn't have
time...
Thanks,
Ephraim
-Original Message-
From: Tielman de Villiers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 15:38
To: Ephraim Dan
Subject: RE: FW: memory leak in DBI ...
perl v5.8.7
DBI ver 1.50:
before | total pid size: 6024 kB
1 | total pid size: 9152 kB (+3128 kB)
101 | total pid size: 9152 kB (+3128 kB)
201 | total pid size: 9152 kB (+3128 kB)
301 | total pid size: 9208 kB (+3184 kB)
401 | total pid size: 9208 kB (+3184 kB)
501 | total pid size: 9208 kB (+3184 kB)
601 | total pid size: 9208 kB (+3184 kB)
701 | total pid size: 9208 kB (+3184 kB)
801 | total pid size: 9208 kB (+3184 kB)
901 | total pid size: 9208 kB (+3184 kB)
after | total pid size: 9332 kB
DBI 1.51:
before | total pid size: 5988 kB
1 | total pid size: 9116 kB (+3128 kB)
101 | total pid size: 9116 kB (+3128 kB)
201 | total pid size: 9116 kB (+3128 kB)
301 | total pid size: 9172 kB (+3184 kB)
401 | total pid size: 9172 kB (+3184 kB)
501 | total pid size: 9172 kB (+3184 kB)
601 | total pid size: 9172 kB (+3184 kB)
701 | total pid size: 9172 kB (+3184 kB)
801 | total pid size: 9172 kB (+3184 kB)
901 | total pid size: 9172 kB (+3184 kB)
after | total pid size: 9296 kB
On Tue, 2006-07-18 at 05:31 -0700, Ephraim Dan wrote:
What results did this give you?
Thanks for testing.
I'll send you my test script soon.
-Original Message-
From: Tielman de Villiers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 15:29
To: Ephraim Dan
Subject: Re: FW: memory leak in DBI ...
Hi Ephraim,
I can have a look at this for you, could you pls send me your test
script for the mem leaks? (I'll leave it up to you to post the results
to the list).
--tielman
I've tested something like the below, but not sure if that gives the
results you want (linux)?
__START__
my @statusArray;
@statusArray = split (/\s+/, `grep Vm /proc/$$/status`);
printf before | total pid size: %5d kB\n, $statusArray[1];
my $startmem = $statusArray[1];
use DBI;
##my $dbh = DBI-connect( dbi:Pg:dbname=test;host=xx, user,
secret );
for my $i ( 1 .. 1000 ) {
my $dbh = DBI-connect( dbi:Pg:dbname=test;host=xx, user,
secret );
my $sth = $dbh-prepare(SELECT * FROM test);
$sth-execute();
$sth-finish;
$dbh-disconnect;
@statusArray = split (/\s+/, `grep Vm /proc/$$/status`);
if ( $i % 100 == 1 ) {
printf %6d | total pid size: %5d kB (+%3d kB)\n, $i,
$statusArray[1], $statusArray[1] - $startmem;
}
}
##$dbh-disconnect;
@statusArray = split (/\s+/, `grep Vm /proc/$$/status`);
printf after | total pid size: %5d kB\n, $statusArray[1];
__END__
On Mon, 2006-07-17 at 20:41 +0100, Tielman de Villiers wrote:
-Original Message-
From: Ephraim Dan [mailto:[EMAIL PROTECTED]
Sent: 17 July 2006 18:39
To: Ephraim Dan; Tim Bunce
Cc: dbi-users@perl.org
Subject: RE: memory leak in DBI ...
Tim,
Any chance you've had a chance to look at this?
Can someone else try to reproduce a memory leak in a simple
connect/prepare/execute/disconnect loop using DBI 1.51 and
any DBD driver?
Thanks...
--edan
From: Ephraim Dan [mailto:[EMAIL PROTECTED]
Sent: Thu 7/13/2006 11:02
To: Tim Bunce
Cc: dbi-users@perl.org
Subject: RE: memory leak in DBI XS bootstrap code
I've just noticed that you're using 5.8.0. Try the latest 5.8.x.
[edan] We can't upgrade perl very easily in our production
environment, but I tested on another box running perl 5.8.8,
DBI 1.50, and I get the same leak of 4 per loop.
Any chance you could find the time to attempt to reproduce
this yourself?
Thanks,
edan
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**
Test t/24implicit_utf8.t fails when compiling DBD-Oracle-1.17
I am getting the following error when I am
trying to make test. The environment is Solaris 10 using PERL 5.8.8, DBI 1.51
and DBD 1.17.
t/24implicit_utf8...NOK 33# Failed test
'byte_string test of row 4: column: nch (uft8) smiley
face'# in t/nchar_test_lib.pl at line
341.# got:
'38|58'# expected: '226|152|186'
# Failed test 'nice_string test of row 4:
column: nch (uft8) smiley face'# in t/nchar_test_lib.pl at
line 344.t/24implicit_utf8...NOK
34# got:
':'# expected:
'\x{263A}'# row 4: DUMP(nch) = Typ=1 Len=4:
0,38,0,58
t/24implicit_utf8...NOK 70# Failed test
'byte_string test of row 4: column: nch (uft8) smiley
face'# in t/nchar_test_lib.pl at line
341.# got:
'38|58'# expected: '226|152|186'
# Failed test 'nice_string test of row 4:
column: nch (uft8) smiley face'# in t/nchar_test_lib.pl at
line 344.t/24implicit_utf8...NOK
71# got:
':'# expected:
'\x{263A}'# row 4: DUMP(nch) = Typ=1 Len=4: 0,38,0,58#
Looks like you failed 4 tests of
74.t/24implicit_utf8...dubious
Test returned status 4 (wstat 1024, 0x400)DIED. FAILED tests 33-34,
70-71 Failed 4/74 tests, 94.59%
okayt/25plsql...okt/30longok
122/470 skipped: various
reasonst/31lob.okt/40ph_type.ok 1/19
Placeholder behaviour for ora_type=1 (the default) varies with Oracle
version.Oracle 7 didn't strip trailing spaces, Oracle 8 did, until
9.2.xYour system doesn't. If that seems odd, let us
know.t/40ph_type.okt/50cursor..okt/55nested..okt/60reauth..okt/70metaokFailed
Test Stat Wstat Total Fail
Failed List of
Failed---t/24implicit_utf8.t
4 1024 74 4 5.41%
33-34 70-71
HAVE U ENCOUNTERED THE SAME
Regards
==
Shiva Subramaniam
Re: Test t/24implicit_utf8.t fails when compiling DBD-Oracle-1.17
Yes we have seen that one before there is an
open bug report for it here
http://rt.cpan.org/Public/Bug/Display.html?id=18012
can you fill in the rest of this table for
me
Perl: 5.8.8DBI: 1.5.1DBD::Oracle:
1.17OS: ?Oracle server: ?Oracle client: ?Oracle database
charset: ?Oracle nchar charset: ?NLS_LANG env var: ?
so I can compare it to other bugs people are
reporting.
As well you will find a work around for this bug
on the error report.
Most likely a fix for this will not get in the
next release as I am having some problem recreating it locally and then
tracking it down as it is deep within the code. I suspect it may be an Oracle
bug but I cant' prove that yet either.
CheersJohn ScolesMaintainer
Oracle:DBD
- Original Message -
From:
Shiva Subramaniam
To: dbi-users@perl.org
Sent: Tuesday, July 18, 2006 4:25
AM
Subject: Test t/24implicit_utf8.t fails
when compiling DBD-Oracle-1.17
I am getting the following error when I am
trying to make test. The environment is Solaris 10 using PERL 5.8.8, DBI 1.51
and DBD 1.17.
t/24implicit_utf8...NOK 33# Failed
test 'byte_string test of row 4: column: nch (uft8) smiley
face'# in t/nchar_test_lib.pl at line
341.# got:
'38|58'# expected:
'226|152|186'
# Failed test 'nice_string test of row 4:
column: nch (uft8) smiley face'# in t/nchar_test_lib.pl
at line 344.t/24implicit_utf8...NOK
34# got:
':'# expected:
'\x{263A}'# row 4: DUMP(nch) = Typ=1 Len=4:
0,38,0,58
t/24implicit_utf8...NOK 70# Failed
test 'byte_string test of row 4: column: nch (uft8) smiley
face'# in t/nchar_test_lib.pl at line
341.# got:
'38|58'# expected:
'226|152|186'
# Failed test 'nice_string test of row 4:
column: nch (uft8) smiley face'# in t/nchar_test_lib.pl
at line 344.t/24implicit_utf8...NOK
71# got:
':'# expected:
'\x{263A}'# row 4: DUMP(nch) = Typ=1 Len=4:
0,38,0,58# Looks like you failed 4 tests of
74.t/24implicit_utf8...dubious
Test returned status 4 (wstat 1024, 0x400)DIED. FAILED tests 33-34,
70-71 Failed 4/74 tests, 94.59%
okayt/25plsql...okt/30longok
122/470 skipped: various
reasonst/31lob.okt/40ph_type.ok 1/19
Placeholder behaviour for ora_type=1 (the default) varies with Oracle
version.Oracle 7 didn't strip trailing spaces, Oracle 8 did, until
9.2.xYour system doesn't. If that seems odd, let us
know.t/40ph_type.okt/50cursor..okt/55nested..okt/60reauth..okt/70metaokFailed
Test Stat Wstat Total
Fail Failed List of
Failed---t/24implicit_utf8.t
4 1024 74 4 5.41%
33-34 70-71
HAVE U ENCOUNTERED THE SAME
Regards
==
Shiva Subramaniam
DBD-Oracle 1.17 gives install_driver(Oracle) failed
I was using Perl 5.6.x (ActiveState Windows port) to connect to Oracle 9i. The modules used then were DBI 1.48 and DBD-Oracle 1.16. I have now upgraded to Perl 5.8.8 with DBI 1.50 and DBD-Oracle 1.17. The upgrade was necessitated by the WWW::Babelfish module. Now while I'm able to use Babelfish properly, my Perl scripts are not able to connect to the Oracle database. The message send to the browser is as follows: cut install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 19) line 3 Compilation failed in require at (eval 19) line 3. Perhaps a required shared library or dll isn't installed where expected at C:/Program Files/Apache Group/Apache2/cgi-bin/iLCLP/iLP_Lgn.pl line 270 /cut While this is a frequent problem as seen by Google results, solutions are rare. Any hints would be welcome. TIA. -- Rohit V. Bhute http://blog.rvbhute.org
Re: DBD-Oracle 1.17 gives install_driver(Oracle) failed
You will have to update DBI and DBD::Oracle from ActiveState. The only problem I see is the version of DBD::Oracle 1.17 will only work for a limited numer of Oracle clients ( Instantclient 10.2.0.1 and I think 10XE.) and windos OSes. You will have to download that client from Oracle and use it or you will have to follow the instrunctions in the README.win32.txt http://svn.perl.org/modules/dbd-oracle/trunk/README.win32.txt to compile it yourselft. I suggest you use the latest trunk version of the code and you can get it here http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.18-RC3.zip as we are close to releaseing a new version of DBD::Oracle Cheers John Scoles - Original Message - From: Rohit V Bhute [EMAIL PROTECTED] To: dbi-users@perl.org Sent: Tuesday, July 18, 2006 12:39 PM Subject: DBD-Oracle 1.17 gives install_driver(Oracle) failed I was using Perl 5.6.x (ActiveState Windows port) to connect to Oracle 9i. The modules used then were DBI 1.48 and DBD-Oracle 1.16. I have now upgraded to Perl 5.8.8 with DBI 1.50 and DBD-Oracle 1.17. The upgrade was necessitated by the WWW::Babelfish module. Now while I'm able to use Babelfish properly, my Perl scripts are not able to connect to the Oracle database. The message send to the browser is as follows: cut install_driver(Oracle) failed: Can't load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: load_file:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 230. at (eval 19) line 3 Compilation failed in require at (eval 19) line 3. Perhaps a required shared library or dll isn't installed where expected at C:/Program Files/Apache Group/Apache2/cgi-bin/iLCLP/iLP_Lgn.pl line 270 /cut While this is a frequent problem as seen by Google results, solutions are rare. Any hints would be welcome. TIA. -- Rohit V. Bhute http://blog.rvbhute.org
Segfault with DBD::Oracle 1.17 under mod_perl
Hi, I built DBD::Oracle 1.17 on a RHEL AS4 machine using the Instant Client libraries. I can use it and DBI 1.48 quite successfully to connect to our Oracle 10 server via CGI or command-line perl. The same code, however, segfaults with the stack trace attached below when run in a mod_perl environment. Each thread connects to the database succesfully (as verified by v$session), but dies whenever I call execute() on a statement handle (prepare is ok). I'm not really sure where to go from here. ldd doesn't list any unresolved dependencies for libclntsh (see below), but at runtime it can't locate some symbols? I didn't see any other reports of this in google, but there were some mentions of segfaults if $ORACLE_HOME is not set. I don't have that in my command-line environment (where SELECTs work), so I crossed that off my list of potential problems. stack dump from gdb attached to httpd: #0 0x00784416 in do_lookup_x () from /lib/ld-linux.so.2 #1 0x00784822 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2 #2 0x00787be6 in fixup () from /lib/ld-linux.so.2 #3 0x00787b20 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #4 0x064e4be6 in kpuexInitStmh () from /usr/lib/libclntsh.so.10.1 #5 0x064e52e9 in kpuexCallback () from /usr/lib/libclntsh.so.10.1 #6 0x06866e31 in ttcdrv () from /usr/lib/libclntsh.so.10.1 #7 0x0674e244 in nioqwa () from /usr/lib/libclntsh.so.10.1 #8 0x065bb27c in upirtrc () from /usr/lib/libclntsh.so.10.1 #9 0x06530b52 in kpurcsc () from /usr/lib/libclntsh.so.10.1 #10 0x064e6407 in kpuexecv8 () from /usr/lib/libclntsh.so.10.1 #11 0x064e8987 in kpuexec () from /usr/lib/libclntsh.so.10.1 #12 0x065bfe1e in OCIStmtExecute () from /usr/lib/libclntsh.so.10.1 #13 0x004bd44d in ora_describe () from /home/bmaust/lib/auto/DBD/Oracle/Oracle.so #14 0x004c0418 in ora_st_prepare () from /home/bmaust/lib/auto/DBD/Oracle/Oracle.so #15 0x004a91e9 in XS_DBD__Oracle__st__prepare () from /home/bmaust/lib/auto/DBD/Oracle/Oracle.so #16 0x01028a82 in Perl_pp_entersub () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #17 0x0100be8d in Perl_runops_debug () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #18 0x00fb6ae6 in Perl_get_cv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #19 0x00fbcc7e in Perl_call_sv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #20 0x003e7a12 in XS_DBI_dispatch (my_perl=0x8648250, cv=0x8d781a8) at DBI.xs:2674 #21 0x01028a82 in Perl_pp_entersub () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #22 0x0100be8d in Perl_runops_debug () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #23 0x00fb6ae6 in Perl_get_cv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #24 0x00fbcc7e in Perl_call_sv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #25 0x003e7a12 in XS_DBI_dispatch (my_perl=0x8648250, cv=0x8d786f4) at DBI.xs:2674 #26 0x01028a82 in Perl_pp_entersub () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #27 0x0100be8d in Perl_runops_debug () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #28 0x00fb6ae6 in Perl_get_cv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #29 0x00fbcea7 in Perl_call_sv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #30 0x00ac7cf4 in modperl_callback () from /etc/httpd/modules/mod_perl.so #31 0x00ac84cb in modperl_callback_run_handlers () from /etc/httpd/modules/mod_perl.so #32 0x00ac878a in modperl_callback_per_dir () from /etc/httpd/modules/mod_perl.so #33 0x00ac3560 in modperl_response_finish () from /etc/httpd/modules/mod_perl.so #34 0x00ac3638 in modperl_response_handler () from /etc/httpd/modules/mod_perl.so #35 0x001969b7 in ap_run_handler () from /usr/sbin/httpd #36 0x00196e23 in ap_invoke_handler () from /usr/sbin/httpd #37 0x001938b5 in ap_process_request () from /usr/sbin/httpd #38 0x0018e63f in _start () from /usr/sbin/httpd #39 0x094da368 in ?? () #40 0x0004 in ?? () #41 0x094da368 in ?? () #42 0x00adbd89 in modperl_process_connection_handler () from /etc/httpd/modules/mod_perl.so #43 0x001a1329 in ap_run_process_connection () from /usr/sbin/httpd #44 0x001a1694 in ap_process_connection () from /usr/sbin/httpd #45 0x00194901 in ap_graceful_stop_signalled () from /usr/sbin/httpd #46 0x00194b44 in ap_graceful_stop_signalled () from /usr/sbin/httpd #47 0x001952fa in ap_mpm_run () from /usr/sbin/httpd #48 0x0019c34a in main () from /usr/sbin/httpd $ ldd /usr/lib/libclntsh.so libnnz10.so = /usr/lib/libnnz10.so (0x00111000) libdl.so.2 = /lib/libdl.so.2 (0x00316000) libm.so.6 = /lib/tls/libm.so.6 (0x004e7000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x0031a000) libnsl.so.1 = /lib/libnsl.so.1 (0x0032c000) libc.so.6 = /lib/tls/libc.so.6 (0x00342000) /lib/ld-linux.so.2 (0x0086f000) -- Brandon
Re: memory leak in DBI ...
On 7/17/06, Ephraim Dan [EMAIL PROTECTED] wrote:
Can someone else try to reproduce a memory leak in a simple
connect/prepare/execute/disconnect loop using DBI 1.51 and any DBD driver?
I created a test program using the test harness distributed with
DBD::Informix and found a small but gentle leak. Over a period of multiple
thousand connections, the Perl executable grew from 866 KB to 973 KB, and
showed no signs of stopping. Is that what you were looking for? (In an
Informix database, the Systables system catalog table is always present.)
This was tested with DBI 1.50 on Solaris 8 (and Perl 5.8.7 - I won't bore
you with why it wasn't 5.8.8). I upgraded to DBI 1.51 (same DBD::Informix
2005.02) and got the same basic result, with Perl growing from 869 to 903
over 2000 iterations.
#!/bin/perl -w
#
# Memory leak test per Ephraim Dan
use strict;
use DBD::Informix::TestHarness;
my $conn_count = 0;
sub test_connection
{
$conn_count++;
my $dbh = connect_to_test_database({ AutoCommit = 0, RaiseError = 1,
PrintError = 1 });
my $sth = $dbh-prepare(SELECT * FROM Systables);
$sth-execute;
$dbh-disconnect;
}
sub test_subroutine
{
while (1)
{
test_connection;
print Connections: $conn_count\n if ($conn_count % 1000 == 0);
}
}
memory_leak_test(\test_subroutine);
exit;
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
DBI-installed_drivers() usage
Im running Win XP with Perl 5.8.8.
If I try and run the following code :
use DBI;
my %drivers = DBI-installed_drivers();
foreach (keys( %drivers)) {
print $_ uses $drivers{$_}\n;
}
Nothing is returned. Yet if I use :
my @drivers = DBI-available_drivers();
I get a list of drivers that I can then access with :
@dataSources = DBI-data_sources($_);
Am I using DBI-installed_drivers() incorrectly?
Regards
Paul
