I have no idea if this is related, but take a look at bugid 20011218.001 at bugs.perl.org. I got a memory leak in perl5.6.0 just by using a local-ized $_ . Your memory leak may have nothing whatsoever to do with Event.
It's fixed in the 5.7 tree, but still broken in 5.6.1. Cheers, John >>>>> "Bradley" == Bradley Brahms <[EMAIL PROTECTED]> writes: Bradley> Uri, thanx for the reply. I will try and download Bradley> Devel::Leak and maybe some other stuff this weekend and take Bradley> it to work with me on Monday. As far as the growth goes, Bradley> yes, the growth goes on and on, with no end. Actually, I did Bradley> not run my latest test with sysread() very long, only a few Bradley> mins, to determine that it did truly end the growth of Bradley> memory. I'll do a longer test on Monday and hopefully still Bradley> have time to do some other firefighting ;) Bradley> I do not believe the problem is sysread(). Nor, do I believe Bradley> it is the <> operator. I have yet to look inside Event.pm. Bradley> Based on my current level of perl knowledge, I'm not even Bradley> sure I could look in to Event.pm and tell much! I know Bradley> Event.pm does not do i/o as I have used truss (a Solaris Bradley> debug tool that shows any/all system calls of a process). Bradley> What I am wondering is if Event.pm does some management or Bradley> something after the select() during the call back that might Bradley> cause memory to fragment. I know it does have to create Bradley> transitory event objects to handle the event. Not sure what Bradley> else. Again, not knowing how perl does garbage collection it Bradley> is hard for me to say. Bradley> Agreed, more testing will need to be done. However, it does Bradley> appear to be some type of interaction caused by Event.pm. Bradley> Brad Bradley> -----Original Message----- From: Uri Guttman Bradley> [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 4:20 Bradley> PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Bradley> [EMAIL PROTECTED] Subject: Re: Is it Event.pm or me that's Bradley> loosing its memory? >>>>> "JS" == Jochen Stenzel <[EMAIL PROTECTED]> writes: JS> Oops. That's surprising. My scripts communicate via IPC::LDT, JS> which Bradley> uses JS> sysread() with read lengths determined dynamically. This would JS> explain why the growth was that unpredictable ... JS> The sysread() read length dependency makes it look like something JS> into perl itself, while on the other hand the Event/select() JS> dependency Bradley> makes JS> it look like something into Event - so maybe Event triggers JS> something Bradley> in JS> perl? I'm afraid I'm no master of perlguts - possibly someone on JS> the list has an insight view or a guess? Bradley> does the process grow forever or does it max out? it may be Bradley> due to some buffer (re)allocations that happen. remember, Bradley> that perl normally doesn't return memory to the system. it Bradley> will keep all the ram is has ever requested for the Bradley> process. if you have odd buffer sizes and they get allocated Bradley> you could be wasting space. i doubt that there is a buffering Bradley> bug with sysread as that is too commonly used and someone Bradley> would have seen something by now. but Event and IO::Select Bradley> don't do any I/O themselves and so should not be affecting Bradley> buffer use. Bradley> there need to be more and better tests to isolate the leak Bradley> (if it exists). there is a module Devel::Leak which may help Bradley> here. you could track who is using the buffers and why they Bradley> (seem to) leak. Bradley> uri Bradley> -- Uri Guttman ------ [EMAIL PROTECTED] -------- Bradley> http://www.stemsystems.com -- Stem is an Open Source Network Bradley> Development Toolkit and Application Suite - ----- Stem and Bradley> Perl Development, Systems Architecture, Design and Coding Bradley> ---- Search or Offer Perl Jobs ---------------------------- Bradley> http://jobs.perl.org
