On Wed, Feb 27, 2002 at 03:06:40PM -0700, Ken Miller wrote: > Subject says it all. I've got some reasonably complicated database code > which utilizes DBI and DBD::Oracle (latest versions as of today) that > appears to be leaking SV's, if Apache::Leak is to be believed: > > ENTER: 59526 SVs > (lots of stuff deleted) > LEAVE: 61113 SVs > ENTER: 61113 SVs > (more stuff deleted) > LEAVE: 61190 SVs > !!! 77 SVs leaked !!! > > Now, I don't really understand how it comes up with 77 SVs leaked, since it > appears that the first ENTER/LEAVE leaked some as well....but that's not my > real question. > > Is there a way to track down where the leaks are occurring without placing > debugging messages everywhere? 77 SVs isn't a lot, but when this many SVs > are leaked per iteration, and you've got about a million rows to rip > through, it adds up to a *lot*.
I need to look into it, (or one of the intrepid souls who have plumbed the depths of DBD::Oracle in the past). I was waiting for new Sun hardware to arrive before working on DBD::Oracle again (Oracle 9i didn't fit on my old Ultra 5 box). The new hardware has arrived but it's broken :-( I'll probably try reinstalling Oracle 8 on the Ultra 5 box so I can at least make some progress meanwhile. I can't make any promises about progress though. It would help *very much* if you, or someone, could narrow down the actions that cause the leak. Just connect/disconnect, or prepare, or prepare+execute, or only with inout placeholders etc etc. > Also, and this is more of a general perl question than a DBI question, but > how does one get leaking SV's with pure perl code? I thought perl was > supposed to take care of cleaning up unused references as soon as they go > out of scope. Some perl things are known to leak, but they're generally fairly rare. String evals that fail with a syntax error spring to mind. > Or, do you only get leaking SVs when XS code is involved? It's certainly *much* easier to make things leak using XS :) Tim.
