How to Explore "Trying to Free an Omnidirectional Scalar

Question

The Perl script (which uses a load of locally written modules and is under active development) has just begun to create sporadic

"Attempt to free the scanner without links: SV 0xa6e685c, Perl-interpreter: 0x96d9008 during global destruction.

messages. This is always repeatable, in the sense that a certain sequence of commands always gives a message if it ever happens, but I was not able to single out a simple or stand-alone case that causes it. In particular, I have not seen it when running the script from the Perl debugger (I can get it when debugging a script that uses IPC :: Open3 to run my target script.)

I understand that this may be a bug in Perl, but it is much more likely that I am doing something, it is very likely that my calls to SVN :: Client; but I am at a standstill to investigate it, and I wondered if anyone had any pointers.

Perl 5.10.0; Different versions of Fedora Linux. I am going to try it on Perl 5.12, but if it does not appear there, it will not help me. Edit : the specific case that reliably gives the message in 5.10 is not contained in 5.12. Unfortunately, this does not tell me anything.

Answer 1

The late answer, but I wrote a long article about this specific topic, which should help in debugging: The Dreaded "Attempting to free an indescribable scalar . "

Answer 2

This is often associated with streaming problems, in particular when transferring a variable from one thread to a routine running in another. Here is an abstract template example:

A.pl

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

B.pm

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

I understand that finding something that resembles this in your “load of locally-written modules” will not be easy. Perhaps you can cut out pieces of your program until you find something that could affect behavior; which should help you isolate the problem.

Answer 3

I also often come across these messages (in code that uses fork lot) and the related problem of segmentation errors during the global destruction phase (that is, the program can function normally, but the error during global destruction can make the program exit with a non-zero exit code) . I also do not know if these problems can be fixed, but usually they can be circumvented.

First use a global variable to determine if you are in the global annihilation phase:

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

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

Then avoid executing the problematic code during the global kill phase:

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

Answer 4

Check for any globs types referenced by pointers, for example. typeglob for hash hashes. I came across this with typeglob used to switch between different hashes of arrays. The error occurred when entries were deleted using both typeglob and the original hash name. Either using a simple hash without nesting, or getting rid of typeglob fixed the problem.

Answer 5

foreach (@var) is another good candidate for verification.

The following code gave me this warning:

 foreach (@list1) { my ($i, $j) = @$_; my $k = get_k($i, $j); foreach (@$k) { sub_that_uses_fork($_); } } 

But the following:

 while (scalar(@list1)) { my ($i, $j) = @{shift(@list1)}; my $k = get_k($i, $j); foreach (@$k) { sub_that_uses_fork($_); } }