Jonathan, thanks for your mail. I still think that dbi-dev is the right place for this. Anyone agrees?
On Fri, Feb 07, 2003 at 06:22:12AM -0800, Jonathan Leffler 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. There's something like that in DBD::Oracle, too. You can run test.pl with -m to run 100 loops. With those 100 iterations, nothing happens. I increased it to 10000, and still: no memory growth. > 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. Well, that's my opinion. I don't think DBI is buggy. > 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). Done. > 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. Haha! I read this and changed my test table to ~17k rows with 5 filled columns of varchar(200). The result? It grows almost as slow as test one. It starts with 16M, gets some more kb at iteration 50, stays like that until it. 200, and ends up at the 10000th iteration with only 500k more than at the beginning. ARGH! > Step 3 is to see whether you can change the blatantly leaky test so > that it doesn't leak. Umh, it's not blatantly leaking yet, I suppose ... But the daemon I was speaking of grew of 40 Megs over the weekend. > 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. Right. Well I am going to use -d again, and maybe Devel::Size. Any other hints on how to track down this bloody thing? TIA Andr� -- Andr� Bonh�te IP Engineer COLT Telecom AG M�rtschenstrasse 27 CH-8048 Z�rich t +41 1 5 600 600 f +41 1 5 600 610 e [EMAIL PROTECTED] www.colt.ch
msg01952/pgp00000.pgp
Description: PGP signature
