$ cat Foo.pm
package Foo;
1;

$ chmod 0200 Foo.pm
$ ls -loanh Foo.pm
--w-------    1 1004           18 Aug  2 10:30 Foo.pm
$ perl -MFoo -e 1
Can't locate Foo.pm in @INC (@INC contains: /etc/perl /usr/local/lib/p
+erl/5.8.3 /usr/local/share/perl/5.8.3 /usr/lib/perl5 /usr/share/perl5
+ /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/
+local/lib/perl/5.8.0 /usr/local/share/perl/5.8.0 .).
BEGIN failed--compilation aborted.
[download]

I tired cat Heavy.pm and cat xSV.pm and had no problems.

Let me lead you through the details, finishing with my educated guess.

As you've noticed, Text::xSV just does a use of Carp. If you look in Carp, it does a delayed load of Carp::Heavy - use Carp any number of times and Carp::Heavy does not get loaded until after you call a function in Carp. (That is the entire idea of Carp::Heavy.) So scattering around another use or 10 of Carp should make no difference.

Now what you're describing could happen if someone assigns to @INC. Then when it finally goes to load Carp::Heavy it cannot find the directory. But you've made it clear that Carp::Heavy is to be found in /usr/lib/perl5/5.8.0, which is in the list of directories that is reported in your error message.

Now you can remove the symptom by setting error_handler in Text::xSV to be any function that you want (either by passing error_handler to new, or by calling the set_error_handler method). However from what you describe, Carp is still messed up, you're just seeing it in Text::xSV because that one is more likely to report an error than anything else. And we still haven't explained why Perl is not behaving as Perl is supposed to behave.

As for Perl's undocumented behaviour, to the best of my knowledge that kind of misbehaviour can only happen for two possible reasons, either deep bugs in Perl, or else you're loading a module written in C that has bugs. My experience suggests that it is far more likely due to a bad module. What can happen with C is that there is a dangling pointer just writing to random memory, literally anything can happen. Changing virtually anything moves stuff around in memory, causing the symptom to move somewhere else. Normally the bug appears somewhere that you won't notice. Sometimes it is visible.

Tracking these kinds of issues down is very hard. When at all possible I'd suggest just reducing the number of C libraries that you load as much as possible to reduce the risk. If there are libraries that you have to load which might be buggy, well I can do more than wish you good luck debugging. Dangling pointers are a notorious nightmare to resolve. :-(

Update: I'm not normally a C programmer, but here is a comparison of some of the tools that I've heard of for catching the kind of C-level bug which I suspect is responsible for your problem. Someone else hopefully has more detailed advice on how to track down the issue.

Thanks for the responce. Other than Text::xSV the script uses DBI, File::Copy and File::Find. I think I'm going to get the Sysadmin (i'm just the webguy) involved in this issue. It sounds like the other responce was right when they said something is seriously fubared. :-( Thanks again

# Add this near the top of your script. 
# The idea is to load it before the error happens
require Carp::Heavy;
[download]