How to investigate " Attempt to free unreferenced scalar"

Question

A Perl script (which uses a load of locally-written modules, and is under active development) has just started producing sporadic

" Attempt to free unreferenced scalar: SV 0xa6e685c, Perl interpreter: 0x96d9008 during global destruction."

messages. This are always repeatable, in the sense that a particular sequence of commands always produces the message if it ever does, but I've not managed to isolate a simple or stand-alone case which elicits it. In particular, I haven't yet seen it when running the script from the Perl debugger (I can get it when debugging a script which uses IPC::Open3 to run my target script.)

I realise that this is just possibly a bug in Perl, but much more likely to be something I'm doing, very likely round my calls to SVN::Client; but I'm stumped for a way to investigate it, and I wondered if anybody had any pointers.

Perl 5.10.0; Various versions of Fedora Linux. I'm going to try it on Perl 5.12, but unless it manifests there too, it won't really help me. Edit: a particular case which reliably gives the message in 5.10 doesn't in 5.12. Unfortunately that doesn't really tell me anything.

Answer 1

Late answer, but I wrote a long article about this particular topic that should help with debugging: The Dreaded "Attempt to free unreferenced scalar".

Answer 2

This is often associated with threading issues, specifically in passing a variable from one thread to a subroutine running in another. Here's an abstract example of the pattern:

A.pl

....
my $dummy;
threads->create("B::c", ($dummy));
....

B.pm

....
sub c{...}
....

I realize that searching for something that resembles this in your "load of locally-written modules" won't be easy. Perhaps you can cut out chunks of your program until you find something that makes a difference in behavior; that should help you isolate the problem.

Answer 3

I also run into these messages a lot (in code that uses fork a lot) and the related problem of segmentation faults during the global destruction phase (that is, the program can complete normally, but an error during global destruction can make the program exit with a non-zero exit code). I also don't know whether these problems can be fixed, but they usually can be worked around.

First, use a global variable to detect whether you are in the global destruction phase:

our $_GLOBAL_DESTRUCTION = 0;
END { $_GLOBAL_DESTRUCTION = 1; }

(see also the ${^GLOBAL_PHASE} variable available in Perl v>=5.13.7)

Then avoid running the troublesome code during the global destruction phase:

sub MyObject::DESTROY {
    return if $_GLOBAL_DESTRUCTION;
    ... # else proceed 
}

sub other_function_that_frees_unreferenced_scalars {
    return if $_GLOBAL_DESTRUCTION;
    ...
}