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: 32396
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: champoux [...] pythian.com
Requestors: David_Kershaw [...] vwr.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 1.17
  • 1.18
  • 1.18a
  • 1.19
  • 1.20
  • 1.21
Fixed in: 1.22



Subject: Memory Leak with update to CLOB column
Date: Thu, 17 Jan 2008 16:03:04 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: David_Kershaw [...] vwr.com
Hello, Our website is experiencing a memory when running a query that updates a CLOB oracle column. Here is an example script that reproduces the issue. #!/usr/local/bin/perl use strict; use DBI; use DBD::Oracle qw(:ora_types); my $dbh = DBI->connect("dbi:Oracle:webdev", "web_user", "web_user", {AutoCommit=>0, RaiseError=>1}); my $sql = q{ UPDATE sessinfo.cgi_sessions SET timestamp = sysdate, data = :data, session_type_id = :type WHERE id = :id }; while (1) { my $sth = $dbh->prepare($sql); $sth->bind_param(':id', 'R455XwwUN40AAFNZhX0'); $sth->bind_param(':data','yo mama',{'ora_type'=>ORA_CLOB()}); $sth->bind_param(':type',1); $sth->execute(); $sth->finish(); $dbh->commit; my $cmd = "grep VmRSS /proc/$$/status"; print `$cmd`; } $dbh->disconnect(); Here is an example output: -bash-2.05b$ ./test_leak.pl VmRSS: 8516 kB VmRSS: 8540 kB VmRSS: 8544 kB VmRSS: 8556 kB VmRSS: 8564 kB VmRSS: 8568 kB VmRSS: 8568 kB VmRSS: 8572 kB VmRSS: 8576 kB VmRSS: 8580 kB VmRSS: 8588 kB VmRSS: 8592 kB VmRSS: 8596 kB VmRSS: 8600 kB VmRSS: 8600 kB VmRSS: 8608 kB VmRSS: 8612 kB VmRSS: 8616 kB VmRSS: 8620 kB VmRSS: 8624 kB ... and goes on Version Info DBD::Oracle 1.19 & 1.15 DBI version 1.50, 1.58, & 1.601 perl v5.8.3 Redhat ES 3.0 (2.4.21-47.ELsmp) Show quoted text
_________________________________ Dave Kershaw Lead Application Developer, e-Business/Technology VWR International, http://www.vwr.com Phone: 610.429.5558 The information contained in this e-mail message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this e-mail message in error please e-mail the sender and delete the message. Thank you.
Will be looking into this report as well as one other earlyer one that is related. I have a hunch were the leak is, DBD::Oracle not releaseing resourses, I will see if I can find a fix for it on the next release
Looking at it the only problem I have is in you program itself Move the prepare out of the loop and it will not leak memory. It is not needed at each iteration The leak maybe in DBI itself. looking at how most of DBI/DBB code should work if you are reusing a prepared statment there is no need to prepare it again each time you change the parameters. I could add code that would test to see it the previous SQL is the same as the SQL being prepared but that would just be doing the programmers job and is not really part of the DBD drivers job. If you are getting this leak when the prepare is outside the loop give me the code and I will look into it again
From: PYTHIAN [...] cpan.org
If you want to check to see if this is a memory leak use prepare_cached that way it will elliminate and false leaks comming from caling the prepare over and over again. The check out the DBI pod here http://search.cpan.org/~timb/DBI- 1.604/DBI.pm#prepare_cached
WAs never really a bug until you try it with prepare_cached and still get the leak
I am sorry you were right all along. There was a leak in the code. Seems a OCI descriptor handle was being created but never released. I also fiex up the code so it would use the Statment handle's descriptor handle so it is garbage collected automatically. This fix sould be in 1.22