m stays alive.
-Original Message-
From: Christopher Jones [mailto:christopher.jo...@oracle.com]
Sent: Monday, January 15, 2018 6:56 PM
To: dbi-users@perl.org
Subject: Re: Hunting down (possible) memory leak in DBD::Oracle
On 16/1/18 9:17 am, Fennell, Brian wrote:
> $ egrep -B1 -A
On 16/1/18 9:17 am, Fennell, Brian wrote:
$ egrep -B1 -A20 -i 'invalid write'
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22
==19402==
==19402== Invalid write of size 4
==19402==at 0xBD747E6: __intel_ssse3_rep_memcpy (in
/db/app/oracle/product/12.1.0/client_1/lib/libclnts
I got this case running with valgrind -
Valgrind reported -
8 invalid writes, 8 invalid writes, 2239 accesses to uninitialized values.
All invalid writes have a stack trace leading back to
XS_DBD__Oracle__st_fetchrow_array (Oracle.xsi:662) and ora_st_fetch
(oci8.c:4032)
Details follow:
export
John,
Thanks for your incites. I tried what you said.
I read up on NVARCHAR2 v VARCHAR2 - interesting. I also see that Oracle has a
way (more than one way) to specify if a VARCHAR2 should contain bytes or
characters - further while a VARCHAR2(11 byte) and a VARCHAR2(11 char) are
different
On 2017-12-19 20:55:30 +, Fennell, Brian wrote:
> And, also with the log level set to 15 here are the LAST 200 lines
[...]
> -> fetchrow_array for DBD::Oracle::st
> (AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
> dbd_st_fetch 6 fields...
> dbd_st_fetched
And, also with the log level set to 15 here are the LAST 200 lines
3abd340 (field=0): '1127646'
field #2 with rc=0(OK)
3abd340 (field=1): '1268251'
field #3 with rc=0(OK)
3abd340 (field=2): 'a...'
field #4 with rc=0(OK)
With the log level set to 15 here are the first 200 lines of log
AAA::DBI::Connection::db=HASH(0x3abce00) trace level set to 0x0/15 (DBI @
0x0/0) in DBI 1.637-ithread (pid 12594)
-> STORE for DBD::Oracle::db
(AAA::DBI::Connection::db=HASH(0x3abce00)~INNER 'RowCacheSize' 2097152)
thr#24d
John,
Thanks for the ideas to change the cache params - I will try that!
Here is the SQL and the field types:
SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
:25 AM
To: John Scoles; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle
John,
Thanks so much for your reply!
I have put off this work for a few years and now the pressure is on - the
original box and OS are so old that the DBA and System Engineer and the
Oper
Pluta,
Looks like it is worth a try - when I looked at the project before it looked
like it was for installing a "per user" perl. Does it work for root / all
users on a box as well?
Brian
Good question - I have asked DBA and am waiting for a reply.
-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org]
Sent: Monday, December 18, 2017 11:36 AM
To: Fennell, Brian ; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL
Ok . . . I am already benefiting from the support from this list : - )
I noticed that I was actually ordering my query BY rownum (which doesn't make
much sense . . . and perhaps oracle's optimizer recognized this and ignored the
pseudo column.)
Just to be sure, I change the query and then rera
John,
Thanks so much for your reply!
I have put off this work for a few years and now the pressure is on - the
original box and OS are so old that the DBA and System Engineer and the
Operations manager have all ganged up on me.
I suppose I could try and work around by downgrading both the perl
, 5
) d
WHERE
d.row_number < 202
AND d.row_number >= 100
-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org]
Sent: Monday, December 18, 2017 9:21 AM
To: Fennell, Brian ; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD:
:19 PM
To: dbi-users@perl.org
Subject: Hunting down (possible) memory leak in DBD::Oracle
Dear DBI people -
I am trying to port some old perl code to a new box. (see Details below)
Needless to say the original box and code works fine, but the new box (and old
code) does not.
Specifically what I
ht it might be an odd string/data related error, but I am
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 ,
$filename )" shows that the error originates inside the DBD::Oracle module
while reading field 3 o
Hi Tim,
Sorry to prolong this.
On 28/05/15 08:58, Tim Bunce wrote:
When a new handle is created the DBI simply pushes a weak reference to
the handle onto the end of the ChildHandles array. Because it's a weak
reference it doesn't interfere with the handle getting destroyed when
the last (non
On Thu, May 28, 2015 at 03:59:51PM +1200, Duncan McEwan wrote:
> On Tue, 26 May 2015 14:13:05 +0100 Tim Bunce wrote:
>
> > I've added this as a note:
> >
> > Note that the ChildHandles array holds weak references and that 'from
> > time to time' the old slots get freed up. This isn't a l
I haven't tried it but you could probably modify the code I posted to test
it. With the statement handle after 120(?) loops of apparent memory leak
+1, there is a correction of -119.
Good luck.
Steve.
On 28 May 2015 05:00, "Duncan McEwan" wrote:
> Apologies for butting in o
Apologies for butting in on this thread, but I saw the following response
from Tim recently and it made me wonder ...
On Tue, 26 May 2015 14:13:05 +0100 Tim Bunce wrote:
> I've added this as a note:
>
> Note that the ChildHandles array holds weak references and that 'from
> time to time
Hi Again
On 26/05/15 10:13, Tim Bunce wrote:
Note that the ChildHandles array holds weak references and that 'from
time to time' the old slots get freed up. This isn't a leak, it just
appears to be if you're not familiar with the caching that DBI does
internally. You can rest
Hi Tim,
Oh yes for (1..500) does exactly that. Thank you. No memory leak at all!
Regards
Steve.
On 26/05/15 10:13, Tim Bunce wrote:
I've added this as a note:
Note that the ChildHandles array holds weak references and that 'from
time to time' the old slots get
> It seems to be further documented here, together with a solution:
>
> http://stackoverflow.com/questions/13338308/perl-dbi-memory-leak,
>
> But the solution does not seem to be reliable. Sometimes it works sometimes
> not.
>
> I'll update you when I know more.
It seems to be further documented here, together with a solution:
http://stackoverflow.com/questions/13338308/perl-dbi-memory-leak,
But the solution does not seem to be reliable. Sometimes it works
sometimes not.
I'll update you when I know more.
Regards,
Steve.
On 26/05/15 07:07,
_TEST; " results in the
leak of one scalar value. It seems to be attached to the ->prepare
statement.
At first I assumed it was down to my Firebird driver, which is
relatively new, so I switched the driver to ODBC::Firebird, with the
same result. Finally I changed to mysql and again got
On Sun, Oct 21, 2007 at 09:48:44PM +0100, Tim Bunce wrote:
> Hello Tim,
I somehow missed the section of the docs that said to email the list, not
Tim. :-)
Tim added the "? DBD::Pg" to the subject. I didn't even think to check out
DBD::Pg's open bugs. Turns out this has already been found and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Bunce wrote:
> - Forwarded message from Troy Davis <[EMAIL PROTECTED]> -
> # The database is Postgres and the "blob" column is of type bytea.
As Troy mentioned BYTEA, I remembered I often noticed memory leaks when
dealing with this kind of
- Forwarded message from Troy Davis <[EMAIL PROTECTED]> -
x-pobox-client-address: 216.37.68.82
x-pobox-client-name: cafeautism.net
Date: Sat, 20 Oct 2007 11:22:42 -0500
From: Troy Davis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Strange memory leak (?) with DBI
Hell
ED]>
Sent: Tuesday, May 22, 2007 7:42 AM
Subject: Re: Memory leak, DBI 1.55 + DBD::ODBC 1.13 + MS SQL 2000
John,
No. I am running this script just from the shell.
Fi.
On 5/22/07, John Scoles <[EMAIL PROTECTED]> wrote:
Are you using IIS7?
- Original Message -
From: &quo
PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, May 21, 2007 4:42 PM
Subject: Memory leak, DBI 1.55 + DBD::ODBC 1.13 + MS SQL 2000
> Hi All!
>
> Recently I have bumped into a memory leak happening in DBI.
>
> Running DBI version 1.55, DBD::ODBC version 1.13 on W
Are you using IIS7?
- Original Message -
From: "Fi Dot" <[EMAIL PROTECTED]>
To:
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, May 21, 2007 4:42 PM
Subject: Memory leak, DBI 1.55
Hi All!
Recently I have bumped into a memory leak happening in DBI.
Running DBI version 1.55, DBD::ODBC version 1.13 on Windows XP SP2,
Active State Active Perl 5.8 build 819. More comprehensive build info
at the bottom of this email.
You could find the code I am executing attached to this
Hi, I'm no Perl expert, but I also would not consider myself a newbie. I
seem to have a memory leak issue with the DBI module (1.52) on Windows
connecting to Oracle (10gR2).
For reasons I won't go into at this time, I need to have a continuous loop
that will connect to many Oracle
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 sma
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...
T
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]
> 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
On Wed, Jul 12, 2006 at 10:44:38PM -0700, Ephraim Dan wrote:
>
> > Did you try the other suggestions?
> > How much improvement did each give? (when testing by destroying the
> > interpreter)
>
> Yeah, sorry I didn't give more detail on that. Here goes:
>
> The first change (Doru Petrescu):
> No
gt; edan
> >
> > > > > -Original Message-
> > > > > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, July 11, 2006 16:59
> > > > > To: Ephraim Dan
> > > > > Cc: Tim Bunce; dbi-users@perl.org
-Original Message-
> > > > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, July 11, 2006 16:59
> > > > To: Ephraim Dan
> > > > Cc: Tim Bunce; dbi-users@perl.org
> > > > Subject: Re: memory leak in DBI XS bootstrap code
iginal Message-
> > > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, July 11, 2006 16:59
> > > To: Ephraim Dan
> > > Cc: Tim Bunce; dbi-users@perl.org
> > > Subject: Re: memory leak in DBI XS bootstrap code
> > >
> > >
o avail.
> I am pretty sure it's in the XS code, but I can't be sure. I tried
> using Devel::Cycle to see if it's a circular reference, but it didn't
> show anything. I don't know of other ways to make a memory leak in
> pure perl, which is why I suspect XS.
&g
reference, but it didn't show anything.
I don't know of other ways to make a memory leak in pure perl, which is why I
suspect XS.
I tried to use Devel::LeakTrace to find where the leaks are, but I'm not so
sure of its results. For what it's worth, it seems to report
it's leaking, but less - just one of those NULL SV guys.
>
> Can you please help me track this down? I'm still a little scared of the
> DBI.xs internals, despite my recent exposure...
>
> Thanks a lot,
> edan
>
>
> > -Original Message-
> >
ce [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 03, 2006 12:16
> To: Ephraim Dan
> Cc: Tim Bunce; dbi-users@perl.org
> Subject: Re: memory leak in DBI XS bootstrap code
>
> On Sat, Jul 01, 2006 at 10:42:58PM -0700, Ephraim Dan wrote:
> > Thanks for the help Tim! You&#x
ng_sv(SvPV(*svp, lna)) : "";
> ima->flags |= IMA_HAS_USAGE;
> if (trace_msg && DBIS_TRACE_LEVEL >= 11)
> sv_catpvf(trace_msg, ",\nusage: min %d, max %d, '%s'",
>
> > -Original Message-
t; From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 30, 2006 16:33
> To: Ephraim Dan
> Cc: Tim Bunce; dbi-users@perl.org
> Subject: Re: memory leak in DBI XS bootstrap code
>
> On Fri, Jun 30, 2006 at 04:08:46AM -0700, Ephraim Dan wrote:
> >This is why I l
har *buf = malloc_using_sv(strlen(str));
strcpy(buf, str);
return buf;
}
Tim.
>--edan
>
>
>
>
>From: Tim Bunce [mailto:[EMAIL PROTECTED]
>Sent: Fri 6/30/2006 11:35
>To: Ephraim Dan
>Cc: Tim Bunce; dbi-users@perl.
: Ephraim Dan
Cc: Tim Bunce; dbi-users@perl.org
Subject: Re: memory leak in DBI XS bootstrap code
On Fri, Jun 30, 2006 at 12:24:33AM -0700, Ephraim Dan wrote:
> > > I don't see what you mean in the "INSTALL" that comes with perl 5.8.0
> > > (that's what we're
vepv( (svp) ? SvPV(*svp,lna) : "");
But
Tim.
> -edan
>
> > > -----Original Message-
> > > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, June 29, 2006 14:47
> > > To: Ephraim Dan
> > > Cc: dbi-users@pe
ethod... any pointers still
appreciated... Thanks for your help so far, Tim.
-edan
> > -Original Message-
> > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 29, 2006 14:47
> > To: Ephraim Dan
> > Cc: dbi-users@perl.org
> > Subject: Re: me
eone else has the same itch.)
Tim.
> Any further pointers are appreciated...
>
> -edan
>
> > -Original Message-
> > From: Tim Bunce [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 29, 2006 14:47
> > To: Ephraim Dan
> > Cc: dbi-users@perl.org
> >
nt it (of course, this is always preferable to doing it myself).
Any further pointers are appreciated...
-edan
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 29, 2006 14:47
> To: Ephraim Dan
> Cc: dbi-users@perl.org
> Subjec
Try building perl with options to make valgrind leak tracing more
effective (see perl's INSTALL file). That may help you pinpoint
the problem.
Tim.
On Thu, Jun 29, 2006 at 04:33:40AM -0700, Ephraim Dan wrote:
> I am experiencing what I believe to be a memory leak in the DBI bootstrap
I am experiencing what I believe to be a memory leak in the DBI bootstrap code.
This is a problem for me because I am embedding perl in a long-running
program, and DBI is being loaded over and over, so my program grows and grows.
The problem appears to be in the following routines:
boot_DBI
elpful.
>
> Thanks,
>
> David Brewer
>
> ###
> # mssql_leak.t
> #
> # Script for demonstrating substantial memory leak with DBI, DBD::ODBC, and
> # a MSSQL 2000 database.
> #
> # To use this script you must have DBI 1.50, DBD::ODBC 1.13, and owner
&g
could create that might be helpful.
Thanks,
David Brewer
###
# mssql_leak.t
#
# Script for demonstrating substantial memory leak with DBI, DBD::ODBC, and
# a MSSQL 2000 database.
#
# To use this script you must have DBI 1.50
I have not yet been able to replicate in mysql but I spent some time
paring down the query to the minimum version that causes the memory
leak. The results are interesting and I think may point toward
DBD::ODBC being the issue. I don't understand the internals well
enough to be sure of
one kind or another.
> >>
> >> Real leaks leak in proportion to the number of calls made. I'd expect
> >> you to be able to say something like "each call to foo leaks N scalars"
> >> (because 100 calls leak X and 101 calls leak X+N).
> >>
&g
ther.
> >>
> >> Real leaks leak in proportion to the number of calls made. I'd expect
> >> you to be able to say something like "each call to foo leaks N scalars"
> >> (because 100 calls leak X and 101 calls leak X+N).
> >>
> >> Ca
gt; > ##
> > use strict;
> > use warnings;
> > use DBI;
> >
> > my $dsn = qq{DBI:ODBC:driver={SQL
> > Server};Server=SERVERNAME;database=DBNAME;uid=DBUSER;pwd=PASSWORD;};
> > my $options = { RaiseError => 1 } ;
> >
> > use Apache::Lea
use warnings;
> use DBI;
>
> my $dsn = qq{DBI:ODBC:driver={SQL
> Server};Server=SERVERNAME;database=DBNAME;uid=DBUSER;pwd=PASSWORD;};
> my $options = { RaiseError => 1 } ;
>
> use Apache::Leak;
> leak_test {
>my $dbd = DBI->connect($dsn, $options);
> $db
=> 1 } ;
>
> use Apache::Leak;
> leak_test {
>my $dbd = DBI->connect($dsn, $options);
>$dbd->disconnect();
> };
> ##
>
> On 6/2/06, David Brewer <[EMAIL PROTECTED]> wrote:
> >I am having what appears to a memory l
tions = { RaiseError => 1 } ;
use Apache::Leak;
leak_test {
my $dbd = DBI->connect($dsn, $options);
$dbd->disconnect();
};
##
On 6/2/06, David Brewer <[EMAIL PROTECTED]> wrote:
I am having what appears to a memory leak problem on a mod_perl
project
I am having what appears to a memory leak problem on a mod_perl
project I am working on. On the worst case web page (a search results
page) I am leaking an average of about 160k per page load! I think
I've finally isolated the problem and it appears to be related to DBI.
It's very pos
OS: HP-UX 11i
Oracle: 9.2.0.1.0
I've followed some directions to build the DBD::Oracle driver against HP's
depot install of Perl 5.8.2. The make, make test, and make install went fine.
However, when I execute a prepared statement multiple times using DBD::Oracle,
my perl process size grows qui
Ron Wingfield [RW], on Wednesday, December 29, 2004 at 10:29 (-0600)
wrote the following:
RW> I know my comments do not provide an immediate solution, but
RW> this could be a very interesting thread. Infact, I'm going to be
RW> writing some IPC intensive code in the near future, and I want to
RW>
Follett, Robert wrote:
You will get much better performance by connecting once, outside your
foreach loop as well as disconnecting and finishing after the loop.
Having tried this, I can assure you that connecting *inside* the loop
is the only alternative here.
In fact, for every loop iteration, Par
- Original Message -
From: Ing. Branislav Gerzo
To: dbi-users@perl.org
Sent: Thursday, December 30, 2004 2:36 AM
Subject: Parallel::ForkManager && DBI memory leak ?
Hi pals,
this is my first post to this mailing list. I have one problem, it is
maybe for you small,
You will get much better performance by connecting once, outside your
foreach loop as well as disconnecting and finishing after the loop.
Also read up on prepare_cached using bind params. You will want to
prepare outside your foreach as well. The only thing you need to do
inside your loop is as
rl -V for more detail)
- DBI v1.46
- Parallel::ForkManager v0.7.5
under unix systems it worked without any memory leak ?
--
...m8s, cu l8r, Brano.
["I'm very sorry but I ran like a fire hydrant." Michael Curtiz]
Hello,
this is my first post to this mailing list. I have one problem, it is
maybe for you small, but for me a big problem. If I want improve my
scripts I _have_ to use parallel DB access. When I looked around I
come to Parallel::ForkManager module, easy to use.
I do not know Parallel::ForkManager
Hi pals,
this is my first post to this mailing list. I have one problem, it is
maybe for you small, but for me a big problem. If I want improve my
scripts I _have_ to use parallel DB access. When I looked around I
come to Parallel::ForkManager module, easy to use.
When I wrote script, I saw it is
perl (5.8.4) on Panther and
made sure I compiled it without multi-threading support. Sure enough,
when I install DBI and DBD::Oracle against that custom-built perl, the
memory leak disappears.
This is probably worth mentioning in the README.macosx. Basically, you
won't be able to use DBD::Or
::Oracle::dr
(DBI::dr=HASH(0x180785c)~0x1860470) thr#1800200
<- disconnect_all= (not implemented) at
/sw/lib/perl5/5.8.1/darwin-thread-multi-2level/DBI.pm line 653 via
dbd-ora.pl line 0
! >> DESTROY DISPATCH (DBI::dr=HASH(0x1860470) rc1/1 @1 g0 ima4
pid#8122) d
If I run the test case code enclosed below against an Oracle database
(first arg dbi:Oracle:blah) the memory consumption goes continuously up
from a few MB to eventually more than 100MB.
If I run the same code against a MySQL database (first arg
dbi:mysql:database=blah, using DBD::mysql v2.9003
Hi All,
I am using
Fedora Linux Core 1 and redHat 8.0
oraclie client 9.2.0.1.0
DBI 1.37
DBD::Oracle 1.15
I seem to have a memory leak problem when using bind variables and the
same prepared statement for hundreds of thousands of rows. Below is my
function call. For my test I have only one
On Wed, 12 Nov 2003, Tim Bunce wrote:
> On Wed, Nov 12, 2003 at 12:34:08PM +0100, Roman Hochleitner wrote:
> >
> > repeated connects to 2 or more 8.1.7 DBs OR schematas DOES leak
> > repeated connects to only ONE (or more) 9.2.0 DB DOES leak
>
> > so the conclusion could be that it looks like th
The patch works OK!
I have to apologise - it was my mistake. There are two versions of Perl on my
mashine - the patch was installed on 5.8.3 and I was testing on 5.6.1. Now
everything works fine on both versions.
Thanks a lot!
> Interesting. I just tried it on my computer and it seems to g
Hello,
I found that some of my perl programs using DBD::Oracle are leaking. It
seems to be similar to:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg19296.html
So far I found that:
* it's leaking on PC and also solaris
* DBD::Oracle-1.13 and 1.14 seems to be affected, 1.12 is ok (on both PC
On Tue, 27 Jan 2004, Zhivko Duchev wrote:
> Thanks for the information!
> Unfortunately the patch did not solve the problem.
Interesting. I just tried it on my computer and it seems to get rid the
(a?) leak.
I modified your code a tad, and this is what I am testing with:
my
$dbh1=DBI->connec
Hello All,
> >
> > I think this is is an old known problem
> > (http://www.mail-archive.com/[EMAIL PROTECTED]/msg18506.html), but just
> > to be sure:
>
> I think this one is a new problem... And it looks to be my fault :(
>
> > There is a memory leak when usi
On Tue, 20 Jan 2004, Zhivko Duchev wrote:
> Hello All,
>
> I think this is is an old known problem
> (http://www.mail-archive.com/[EMAIL PROTECTED]/msg18506.html), but just to
> be sure:
I think this one is a new problem... And it looks to be my fault :(
> There is a memo
Hello All,
I think this is is an old known problem
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg18506.html), but just to
be sure:
There is a memory leak when using binding and multiply executes also in
DBD::Pg 1.31.
The following script reproduces the problem:
use DBI ;
use DBD::Pg qw
I've attached a little script which replicates the problem on my machine as well as
the build session log for DBD::Oracle 1.14.
I've tested it using DBI 1.38 and DBI 1.28 with both DBD::Oracle 1.12 and 1.14.
Regardless of the DBI version, DBD::Oracle 1.14 leaks on my system and DBD::Oracle
1.12
til I got this remainder.
> >
> > The funny thing is: if you connect/disconnect to only one and the same
> > database, there is no memory leak, but if you alternate between at least
> > two databases, it starts growing.
>
> Interesting. Probably means an Oracle issue tho
On Wed, Nov 12, 2003 at 12:34:08PM +0100, Roman Hochleitner wrote:
>
> repeated connects to 2 or more 8.1.7 DBs OR schematas DOES leak
> repeated connects to only ONE (or more) 9.2.0 DB DOES leak
> so the conclusion could be that it looks like the problem is more/only
> related to the DBD::Oracl
On Wed, Nov 05, 2003 at 03:15:40PM +0100, Roman Hochleitner wrote:
>
> Hi!
>
> We are using Oracle 8.1.7 server/client under Redhat 7.1 perl 5.6.0 with
> DBD::Oracle V1.14 and DBI V1.37.
>
> With the attached script I can reproduce a memory leak growing at a rate
> o
to 1.38 and the
>> perl 5.8.1(not that this is affecting the memory leak). If you search the
>> archives, DBI 1.37 seems to had memory leak problems with other drivers as
>> well. So I would say you might want to upgrade to the latest DBI(1.38).
>
> Thank you,
>
>
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote:
>
> I was just debugging this problem for co-workers, on RedHat 7.3 perl 5.6.1,
> DBI 1.37 & DBD::Oracle 1.14. I am going to upgrade the DBI to 1.38 and the
> perl 5.8.1(not that this is affecting the memory leak). If you search the
I was just debugging this problem for co-workers, on RedHat 7.3 perl 5.6.1,
DBI 1.37 & DBD::Oracle 1.14. I am going to upgrade the DBI to 1.38 and the
perl 5.8.1(not that this is affecting the memory leak). If you search the
archives, DBI 1.37 seems to had memory leak problems with o
Hi!
We are using Oracle 8.1.7 server/client under Redhat 7.1 perl 5.6.0 with
DBD::Oracle V1.14 and DBI V1.37.
With the attached script I can reproduce a memory leak growing at a rate
of about 12MB/min. We use scripts simmiliar to that for monitoring
(nocol/snips client).
At first I searched
Sep 24, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I'm working in a database migration project (Sybase ASE -> DB2 V8) with perl, DBI
> > and DBD::DB2 and we have a memory leak problem when we run a lot of select
> > statements du
On Wed, Sep 24, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I'm working in a database migration project (Sybase ASE -> DB2 V8) with perl, DBI
> and DBD::DB2 and we have a memory leak problem when we run a lot of select
> statements during data import/
Hi all,
I'm working in a database migration project (Sybase ASE -> DB2 V8) with perl, DBI and
DBD::DB2 and we have a memory leak problem when we run a lot of select statements
during data import/export.
We tested the System with different combinations of DBI (1.20 - 1.38), DBD::DB
On Thu, 18 Sep 2003, Thomas L. Shinnick wrote:
> Been around the block on this one so I might be ... confusing.
>
> I believe that the single prepare() with placeholders and multiple
> execute()s with bind values has a memory leak. Program memory size
> grows in proportion to num
Thomas L. Shinnick said:
> I believe that the single prepare() with placeholders and multiple
> execute()s with bind values has a memory leak. Program memory size
> grows in proportion to number of INSERT's and average data size.
> Memory is not released until program terminatio
Been around the block on this one so I might be ... confusing.
I believe that the single prepare() with placeholders and multiple
execute()s with bind values has a memory leak. Program memory size
grows in proportion to number of INSERT's and average data size.
Memory is not released
I know this was discussed before, but I don't if anything came out of it.
I upgraded one of our servers to DBD::mysql 2.9002 and suddenly one of our
programs grows in memory until it runs out. I ran the same program on my
server which had 2.1020, no problems, then I upgraded to version 2.9002
an
Hi TIM,
I've tried your fix and now this is OK.
thanks for your help.
rgds,
David
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: vendredi 4 juillet 2003 14:22
To: Guillaume, David [CTF:8D60:EXCH]
Cc: 'Tim Bunce'; '[EMAIL PROTECTED]'
Su
1 - 100 of 187 matches
Mail list logo
