Cómo investigar "intento de liberar a escalar sin referencias"

Question

guión Un Perl (que utiliza una carga de módulos localmente escritos, y está en desarrollo activo) acaba de comenzar la producción esporádica

"intento de liberar a escalar sin referencias: SV 0xa6e685c, intérprete de Perl: 0x96d9008 durante la destrucción global. "

mensajes. Esto siempre es repetible, en el sentido de que una secuencia particular de comandos siempre produce el mensaje si alguna vez lo hace, pero no he logrado aislar un caso simple o independiente que lo provoque. En particular, todavía no lo he visto cuando ejecuto el script desde el depurador Perl (puedo obtenerlo al depurar un script que usa IPC :: Open3 para ejecutar mi script de destino).

Me doy cuenta de que esto es solo posiblemente un error en Perl, pero es mucho más probable que sea algo que estoy haciendo, muy probablemente en mis llamadas a SVN :: Client; pero estoy perplejo por una forma de investigarlo, y me pregunté si alguien tenía alguna indicación.

Perl 5.10.0; Varias versiones de Fedora Linux. Voy a probarlo en Perl 5.12, pero a menos que se manifieste allí también, realmente no me ayudará. Editar: un caso particular que da confiablemente el mensaje en 5.10 no en 5.12. Lamentablemente, eso realmente no me dice nada.

Answer 1

Esto a menudo se asocia con problemas de subprocesamiento, específicamente al pasar una variable de un subproceso a una subrutina que se ejecuta en otro. He aquí un ejemplo abstracto del patrón:

A.pl

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

B.pm

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

Soy consciente de que la búsqueda de algo que se parece a esto en su "carga de los módulos escritos localmente "no serán fáciles. Tal vez pueda cortar trozos de su programa hasta que encuentre algo que haga una diferencia en el comportamiento; eso debería ayudarte a aislar el problema.

Answer 2

También encuentro estos mensajes mucho (en código que usa mucho fork) y el problema relacionado de fallas de segmentación durante la fase de destrucción global (es decir, el programa puede completarse normalmente, pero puede ocurrir un error durante la destrucción global hacer que el programa salga con un código de salida distinto de cero). Tampoco sé si estos problemas pueden solucionarse, pero generalmente se pueden solucionar.

En primer lugar, utilizar una variable global para detectar si se encuentra en la fase de destrucción global:

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

(véase también la ${^GLOBAL_PHASE} variable disponible en Perl v> = 5.13.7)

Entonces evitar ejecutar el código problemático durante la fase de destrucción global:

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

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

Answer 3

respuesta tardía, pero me escribió un largo artículo sobre este tema en particular que shou ld ayuda con la depuración: The Dreaded "Attempt to free unreferenced scalar".

Answer 4

Busque cualquier tipoglobos que hagan referencia a punteros, p. un typeglob para un hash de hashes. Me encontré con esto con un typeglob utilizado para cambiar entre diferentes hashes de matrices.El error surgió cuando las entradas se eliminaron utilizando tanto el typeglob como el hash original. Usar un hash simple sin anidar o deshacerse del typeglob eliminó el problema.

Answer 5

foreach (@var) es otro buen candidato para la inspección.

El siguiente código me dio esta advertencia:

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

pero el siguiente no lo hicieron:

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