On Mon, Jul 29, 2002 at 09:52:33AM -0400, Jeff Urlwin wrote: > Gary -- it's more likely in DBD::ODBC than DBI.
But not by much :) Probably worth trying it with an older version of the DBI as a check. > If you can create a > self-contained sample, it would be greatly appreciated and looked at faster > :) Yes, a _small_ simple self-contained example script is a big help. Copy the problem script and keep cutting away at it till the leak goes away, or it gets so small it's obvious where the problem is. > You didn't indicate if the loop is a set of inserts, queries, etc. Does it > have longs? What's the LongReadLen value? > > If you can, include a drop table and create table statement at the top, > insert test data, then run through something similar to your loop that's > leaking. > > Tim -- if you have suggestions as to how to approach this with Perl, I'd be > very appreciative! The "keep making the sample code smaller" approach usually works well. The Devel::Leak module may be useful: http://search-beta.cpan.org/author/NI-S/Devel-Leak-0.02/Leak.pm Another approach is to let the process grow huge (many MB) then core dump it and look through the binary (using less or other viewer that can read binary) and look for clues/patterns in the leaked memory. Tim. > Regards, > > Jeff > > > > Tim; > > > > I'm using DBI v1.30 and DBD-ODBC v0.43. My database(SQL2000) app > > is invoked about 40,000 times over the course of about 2 days to > > generate test scripts for some automated test equipment. I've > > been noticing the memory usage creeping up over the course of the > > runs (up to Meg per loop at times). I have seen a report on the > > developers mail list regarding this problem in recent versions. > > Have you done any tests to check for leaks, or have you had any > > reports of leaks? Perhaps there is some peculiarity of SQL2000, > > that requires explicit releasing of handles or buffer space? > > > > Any help would be appreciated. > > > > Regards; > > Gary > > > >
