If the world was perfect, perl would not leak memory.
And neither would perl segfault. But the world isn't
perfect, and hence, perl is made by humans, using libraries
made by humans, running on an OS made by humans.
So, perl could segfault. It shouldn't, not even if you make
a syntax error. But it happens.
Now, what the relation is between segfaults and memory leakage
isn't clear to me. Neither should happen - both do.
Oh, and it's very well possible in Perl to have memory that
is no longer accessable, while it will not be garbage collected
until the program ends. That's refcounting for you.
Abigail | [reply] |
If I get a segmentation fault in a perl script, and there are no syntax errors in the code is it always a problem with the interpreter.
The "interepreter" is not necessarily at fault. Many Perl modules use dynamically loaded components that are written in C. These can segfault. On the positive side, most of the ones you get from CPAN have undergone substantial testing.
There is no way to leak memory in a perl environment right?
You can leak memory if you make self-referential data structures. Perl uses a "reference counting" scheme, and only frees objects when their reference count goes to zero. If you make $x a reference to $y, and $y a reference to $x, you have a (small) self-referential data structure that won't be freed unless you first break a reference.
| [reply] |
There are many parties involved in making your Perl Program work and any one of them could be the culprit. Consider the following:
- There is the Perl interpreter. It has "autovivification" which would allow it to create structures as needed (so as to avoid ending up in areas that do not exist). I would not make it the first suspect though. It has been around longer than any program I have written. And people out there aren't having regular seg fault problems.
- You might be using "exec" to run another program and that program might have the segmentation fault. But if it is a simple script, then that might not be applicable.
- You are probably using a module that has pieces coded in other languages. This is the case for example if you are using a Perl module that is a wrapper around a C library. This leaves your Perl program open to seg faults in the C library. You might be sending parameters to your module that don't work for the C module and something bad ends up happening in that part of the code.
- When Perl was compiled on your system, or when the modules used were compiled and installed, there were problems that were not detected or ignored and therefore in certain circumstances, the program dies.
So as we see, we have a bit of a way to go before we blame the Perl interpreter for this one. As far as "Garbage collection", you have to keep your expectations realistic. You cannot write a Perl script to keep allocating memory and things to work hunky dory because, well you don't have a machine with infinite memory (unless I am really out of touch with chip tech).
--
termix
| [reply] |
Personally, the only time I've seen perl segfault on Unix is when the Sybase Open Client libraries crashed the process (after the database server itself crashed).
On Windows, it sometimes happen if I do a perldoc and then press Ctrl-C. Weirdish. But signals aren't that safe, are they?
/J
| [reply] |
| [reply] |