Perl Troubleshooting

This is a collection of fixes for various issues I’ve had with Perl.  Feel free to add any of your Perl tips here.  I will move this to a wiki page if it gets too big.

All Perl scripts fail with error message “Compilation failed in require at…*.pm did not return true at …”

Unable to install packages on Debian with error message “Perl may be unconfigured”

Both of these issues stem from corrupted Perl modules.  Debian must have perl to perform practially any task.  You must fix perl before you can get Debian to cooperate.

Check out where perl is searching for its perl modules using “perl -V”.  You will get a long list of output similar to this.  At the end will the the order of directories that perl looks for its modules by default.

# perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

  Platform:
        . . .  {skipped for brevity } ...
  Built under linux
  Compiled at Mar  6 2013 15:32:40
  @INC:
    /etc/perl
    /usr/local/lib/perl/5.10.1
    /usr/local/share/perl/5.10.1
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl

Check each of those directories in order for the *.pm module file specified the error message.  Most likely there is an issue with the module file in one of the earlier directories – maybe it is 0 Bytes or corrupted.  Even if you have a good verison of the module file in a directory that is searched afterwards, Perl will still crap out, since it found the module file in an earlier directory and can’t read it.  Either clear the earlier directory or copy the good version of the file into the earlier directory.  You will most likely need to be root to do this.

Your system might have gotten into this state after disk failure / disk errors.  Also, you  may have various module versions compiled with different settings.  Try to avoid mixing CPAN and Debian perl module installs – PerlMonks advises against mixing CPAN and Debian perl module installs.

CPAN module fails to install because test fails even though make is successful

You can force a module install in the CPAN shell with “force install My::Module”.

cpan[1]> force install Log::Fast

Unable to Install CPAN Modules because root user home directory is full

If anyone has ever successfully installed CPAN modules locally, tell me your secret.  I always get compiler issues or “unable to connect to internet” issues.  I usually just install CPAN globally as root.  If your root user home directory is full or you are unable to write to it for some reason, you can change the root cpan directory to another directory with more disk space by using the CPAN shell command:

thuy@jabba:~$ cpan

cpan shell -- CPAN exploration and modules installation (v1.960001)
Enter 'h' for help.

cpan[1]> o conf cpan_home                                
    cpan_home          [/home/thuy/.cpan]
Type 'o conf' to view all configuration items

cpan[2]> o conf cpan_home /home/thuy/newcpanfolder
    cpan_home          [/home/thuy/newcpanfolder]
Please use 'o conf commit' to make the config permanent!

cpan[3]> o conf commit
commit: wrote '/home/thuy/.cpan/CPAN/MyConfig.pm'

Other CPAN configurations that you can set

CPU Performance:  Hashes versus CPAN Set modules

Use hashes for set operations on scalars whenever you can. CPAN modules for set operations (finding intersections, differences, unions, etc) between unique sets of scalars make your code easier to follow, but are insanely slow due to Perl’s overhead for object oriented method calls. I found that I got a speed up of 2 to 10 x when I used hashes instead of Set::Scalar.

However, if you need to perform set operations on objects and you need to invoke methods on those objects afterwards, use Set::Object CPAN module instead of hashes.  When you put an object into a hash as a key, perl converts object reference key to string and there is no way to convert the string back to an object reference.

Memory Usage

Say you want to store the contents of your 1 MB file into an array or a hash in Perl.  Perl auto-grows the memory reserved for arrays and hashes in an exponential fashion.    As the actual amount of data stored grows, the memory required by your program grows much faster.  Your 1MB file might end up costing 1GB in memory even though only 1 MB of data is actually stored.  Some people say to estimate your perl program memory consumption, multiply the expected size of your data by 10 – 20 x.

I have not been able to find a way to stop perl’s array/hash auto-grow.  Even explicitly intializing arrays and hashes with the maximum size of the data doesn’t stop the auto-grow.

Perl Multithreading

Perl does not have lightweight threads.  For every thread you launch a complete copy of all the variables from the parent process is made.  Further, none of those variables are shared between threads unless you use the very complicated and heavyweight threads::shared module.  If you are short on RAM, keep this in mind.

If you are not sure whether to use fork (launch child process from parent process) or threads (launch child threads from parent process ), figure out how you want your parent to talk to your children.  If you want your children to be asynchronous and there is no data to pass from child to parent, then use fork.  If you want your parent to wait until your children are done and you want your children to pass data back to the parent, then use threads.