It's not inconcievable a memory leak was introduced in 5.8. Please create a small program that doesn't leak on 5.6, but does leak on 5.8, and report it using perlbug as soon as you can. Jarkko released release candidate 2 for 5.8.1 today, but will be away for the next two weeks, meaning that there is sometime left for someone to write a patch to be included in 5.8.1. Unless the bug is already known and fixed of course. But don't hesitate, spend some time isolating the bug from your code now, otherwise you might have to wait another year or so before there's a perl that doesn't leak memory.

Abigail

There's no magic program that will load another script and point out problems. The only approach will be to instrument you program and get it to report what it's doing.

Without knowing anything specific about your problem, I'd tend to point the finger at DBD::Oracle (if indeed that's what you're using) since it's the largest module you're using and has a healthy portion of XS code in it. Then again, a lot of people have pounded on it for years so the bugs should have been shaken out of it by now. Are you using version 1.14?

Are you using complex regexps (with the /x modifier and (?{...}) or some of the hairier extensions)?

Have you tried using Devel::Leak or Devel::LeakTrace? (you're going to need a perl compiled with -DDEBUGGING in this case).

Can you post any code? Is this 5.8.0 or 5.8.1-RC1?

_____________________________________________
Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.

Sorry, forgot to log on before posting my question.

Perl is v5.8.0.
DBD::Oracle::VERSION = '1.14'

I'm mainly looking for something that will just scan the calls and print out a report, just so I have a list of candidates to narrow down my search as to what's broken, like:
'open' behavior has changed, IO internals have been modified
etc.

pseudocode:

open(INF,"<$filename") || die "Couldn't open in file\n";

my $id = 0;
my $data = "";
...
my $statement = $dbh->prepare("insert into data_table values(:1,:2)");

while(<INF>) {
  if (s/^ID:[\s]+//g) {
    $id = lc($_);
  }
  elsif (s/^Data:[\s]+//g) {
    $data = lc($_);
  }
  #repeat for several labels

  $statement->execute($id,$data);

  $id = 0;
  $data = "";
}
[download]

There's several pieces of data that get pulled out and and compared to the data that exists in the table for a given ID, but this should give an idea of what it's doing.

As far as Devel::Leak, no haven't used it before. Will investigate.

I'll try and break down the code to demonstrate the leak, but I have to figure out for certain what's causing it first.

I seriously doubt that this would cause a memory leak, but that code sample suggests that $id and $data aren't needed outside the while loop. I always try to put variables in the innermost scope that they are needed.

--PotPieMan