eval + no warnings = no memory

[gryng]

#!/usr/bin/perl -w
use strict;

eval 'no warnings' while (0==0);

The above code curiously eats memory like a fiend! I'm not sure if this is expected behavior or not, but it caught me as a surprise while writing a (slightly) more complex program that had the same 'no warnings' within an eval. I don't have a really intellegent guess as to why it would legitimately or illegitimately be doing this, so I'm just throwing this one out there. I've gotten around the problem in my program by removing the need for the 'no warnings'. (It should be noted that if warnings was not turned on initially the program will not thrash the memory). Ciao, Gryn p.s. Hi guys, long time, no code.

[clintp]

Interestingly, it has nothing to do with warnings per se.

Simply running

perl -e "eval  'no strict;' while (0==0);"

But if you use eval BLOCK, this doesn't happen:

perl -e "eval  {no strict;} while (0==0);"

Won't. This is odd, and cause for a bug report.

[tye]

Temporary "scratchpad" variables are not free()d until (roughly) the end of the statement. This statement never ends so each eval allocates a bit of temporary space and these never get free()d.

You can test this by making the loop only repeat a few hundred times and then put that in a bigger loop and see the memory grow initially but then level out as the hundreds of temporaries get free()d each time around the bigger loop.

But I haven't tested this theory, it just seems pretty danged likely. (:

        - tye (but my friends call me "Tye")

[gryng]

I reduced the program to the smallest size, but I can assure you that the behavior happens even if the eval statement is within a loop, or even within a procedure called by a loop (as this was the original case).

But it's a good guess though :)

Ciao,
Gryn

[tye]

Ah, thanks for the info. From elsewhere in this thread, it sounds like the leak is in "stringy" eval for some versions of Perl on some platforms. I'm sure the porters would appreciate a bug report with the data collected so far. (:

        - tye (but my friends call me "Tye")

[MeowChow]

Interesting... it doesn't soak up memory on my Linux Perl 5.005_03 or my Win32 ActiveState Perl 5.6, but it does on my Linux v5.6 and my Win32 Cygwin 5.6...

update: as lemming pointed out, it actually does leak memory under 5.005_03, only very very slowly. It's more of a drip, than a leak, really.

[AgentM]

I ran this on some corporate-grade servers and I also got "Out of Memory!" after 30 seconds or so. What's recursive about this or where is the memory leaking?


AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

[Fastolfe]

Is it really eating up memory or are you wondering why it's pegging your CPU? If it's the former, that almost sounds like a bug. If it's the latter, presumably you are aware that the code above is an infinite loop...

[gryng]

gryn@echor:~/test$ ./test.pl
Out of memory!
gryn@echor:~/test$

The infinite loop is just keep the program running :) .

[gryng]

Grr, wherefore dost my formating break :P , sorry.

Gryn

[ZydecoSue]

You might try adding <P> tags next time.

Just a suggestion.

Update: Question to those voting this down. Why? It's a simple, friendly suggestion that came to mind after I viewed the source of the original post. Take a quick peek; there aren't any <P> tags. Would flagging it as off-topic have made it more palatable?

[gryng]

Thanks ZydecoSue, I swear that I did! :) But something stripped them. I have bad luck with these sorts of things :) .

Ciao,
Gryn