Andre Bonhote wrote:
I don't use DBD::Oracle, but DBD::Informix has a test harness module, and one of the functions in there, memory_leak_test, is specifically for running memory leak tests. It takes a ref to a function. It forks, and the child runs the function, while the parent periodically runs 'ps -fp$childpid'. I've used that many times to track down memory leaks in DBD::Informix and related code. It is actually a generic function; it doesn't care what the function does, and does not depend on DBD::Informix for any functionality. Note that the code in the function should connect to the database, not the code which sets up the call to memory_leak_test. If you wanted to try it, you could download DBD::Informix 1.04.PC1 and then extract memory_leak_test from the file lib/DBD/Informix/TestHarness.pm. You might want to use a minor variation on the 'ps' command you have in place of the one I use by default.On Fri, Feb 07, 2003 at 02:13:51PM +0100, H.Merijn Brand wrote:Hm ...Indeed. Hmm. I don't have any new ideas.Strange enough: DBD::Pg and DBD::mysql works fine without any hassle. Could the Oracle Version be a problem (9i)?
Based on my experience, there is always a chance that there is a memory leak in the database connectivity software. Doubly so if an alternative driver running the same Perl apart from the DBI->connect does not have the leak. There is also a chance that the leak is due to a bug in the DBD code -- I've suffered from both, and more frequently from my coding than from bugs in the database connectivity code. There's an outside chance the bug is in DBI code; I usually put that at the bottom of the probability list, though, especially in a case like yours where it appears that another driver is OK.
Step 1 is to establish that there is a leak - you've done that, I think. Keep the original test code for the record (and proving that the original problem is fixed).
Step 2 is to try and make a slow leak like your into a more serious (blatant) leak without changing the substance of the test. Sometimes, you can do this by changing a CHAR(10) to a CHAR(200); sometimes you select more columns; sometimes you...well, you ring the changes and see what happens.
Step 3 is to see whether you can change the blatantly leaky test so that it doesn't leak. Generally, drivers try to avoid leaks, so there's often something odd about your code compared to anything that the author usually tests. I said 'odd', not 'wrong'. It simply means you've found something legitimate that the author hasn't thought of. I had a leak where people prepared a statement but never used it, for example. Pure oversight in the administrative code. Still a leak. One thing I'd try changing in your code is the selection function -- selectcol_arrayref.
Once you've done that, you may be starting to get an idea about what triggers the leak. And you may have a workaround. And the more precise information may help the author(s) of DBI and the driver (in this case, the same person, of course) track down where the problem is.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix 1.04.PC1 -- http://dbi.perl.org/
