On Mon, Feb 10, 2003 at 11:05:56PM -0800, Jonathan Leffler wrote: > Andre Bonhote wrote: > >thanks for your mail. I still think that dbi-dev is the right > >place for this. Anyone agrees? > > It's really a dbi-user's issue -- it is about a possible bug in DBI, > DBD::Oracle or Oracle itself, rather than a design/implementation > issue common to all driver writers. That isn't a hard'n'fast > determination -- there's room to think that maybe it is partly an > issue that faces each driver writer on occasion.
Ok. The thread is still continuing in dbi-dev, but we can stay here (as it lands in the same folder anyway here). > >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. > > That's irksome; slow leaks are hard to fix, both in tyres (tires for > the American section of the audience) and in code. In other words: It sucks hard. > >Umh, it's not blatantly leaking yet, I suppose ... But the daemon I was > >speaking of grew of 40 Megs over the weekend. > > (40-16)*1024/0.05 = 0.5M > > Presumably, your daemon iterated about half a million times over the > weekend? Does that sound plausible? No. The daemon grows faster. The "SELECT" is a bit more complex. I think I will shrink down the daemon to the select statement and look how it behaves. > What I have done, in some other programs, is use a debugging malloc. > It makes everything run glacially, but you can track exactly which > memory is allocated, and which memory is freed, and you can add calls > to an annotation function to identify places where you code is > executed. This can reveal which part of the code is allocating the > unfreed memory. Ultimately, you could hone in to the individual OCI > call that is leaking - that is, allocating memory which is not > subsequently freed. At that point, you can remove Perl and DBI and > DBD::Oracle from the equation and write a simple, pure C + OCI program > that demonstrates the same leakage -- and the job is done. You can > send stroppy notes to Oracle and wait for the upgrade with the bug > fix. But tracking that sort of leak is painful. Fortunately, Perl > is quite good at processing data... Fact is: I am not a coder. I give myself a perl rating of 3 points out of 5, which means I know how to use perl, but don't know the deep details. Additionally, I don't know C that well :( > If you want to go down this route (which I do regard as a desparation > measure), then contact me for a debugging malloc. No promises that it > will do anything other than make you aware of how much memory is > allocated in your program -- but it might, just conceivably, help. > However, I am not going to be listening to this mailing list for the > rest of this week, so try to find another way to demonstrate the > problem, and/or get someone else's debuggin malloc -- dmalloc from > http://dmalloc.com springs to mind as a possibility worth > investigating. And frankly, apart from possibly supplying a debugging > malloc, there isn't a lot more I can offer in the way of help. You > need Tim Bunce to chip in with any views he has on the subject, but if > the problem is in the OCI itself, there isn't going to be very much he > can do for you either. You helped quite a lot until now with your deep explanations. On dbi-dev, Stephen Clouse is going to try out my script on his Oracle 9.2 installation. We'll see whether he is able to reproduce the leak. Thanks! 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
msg15709/pgp00000.pgp
Description: PGP signature
