Ein Perl-Skript (das eine Ladung von lokal geschriebenen Modulen verwendet und sich in der Entwicklung befindet) hat gerade begonnen, sporadisch zu produzieren
"Versuch, den nicht referenzierten Skalar freizugeben: SV 0xa6e685c, Perl-Interpreter: 0x96d9008 während der globalen Zerstörung. "
Nachrichten. Dies ist immer wiederholbar, in dem Sinne, dass eine bestimmte Sequenz von Befehlen immer die Nachricht erzeugt, wenn sie es jemals tut, aber es ist mir nicht gelungen, einen einfachen oder eigenständigen Fall zu isolieren, der sie hervorruft. Insbesondere habe ich es noch nicht gesehen, wenn ich das Skript vom Perl-Debugger aus starte (ich kann es beim Debuggen eines Skripts bekommen, das IPC :: Open3 verwendet, um mein Zielskript auszuführen.)
Mir ist klar, dass dies möglicherweise nur ein Fehler in Perl ist, aber viel wahrscheinlicher ist es, dass ich etwas mache, sehr wahrscheinlich rund um meine Anrufe bei SVN :: Client; aber ich bin auf der Suche nach einem Weg, um es zu untersuchen, und ich fragte mich, ob jemand irgendwelche Hinweise hatte.
Perl 5.10.0; Verschiedene Versionen von Fedora Linux. Ich werde es auf Perl 5.12 versuchen, aber wenn es sich dort auch nicht manifestiert, wird es mir nicht wirklich helfen. Bearbeiten : Ein bestimmter Fall, der die Nachricht in 5.10 zuverlässig liefert, findet nicht in 5.12 statt. Leider sagt mir das nichts wirklich.
Verspätete Antwort, aber ich habe einen langen Artikel über dieses spezielle Thema geschrieben, der beim Debugging helfen sollte: The Dreaded" Versuch, unreferenzierten Skalar zu befreien ".
Dies ist oft mit Threading-Problemen verbunden, insbesondere beim Übergeben einer Variablen von einem Thread an eine Subroutine, die in einem anderen Thread ausgeführt wird. Hier ist ein abstraktes Beispiel für das Muster:
A.pl
%Vor%B.pm
%Vor%Mir ist klar, dass die Suche nach etwas, das in Ihrer "Ladung lokal geschriebener Module" ähnlich ist, nicht einfach sein wird. Vielleicht können Sie Teile Ihres Programms ausschneiden, bis Sie etwas finden, das einen Unterschied im Verhalten macht; das sollte Ihnen helfen, das Problem zu isolieren.
Ich stoße auch sehr oft auf diese Meldungen (in Code, der fork viel verwendet) und das damit verbundene Problem der Segmentierungsfehler während der globalen Zerstörungsphase (dh das Programm kann normal abgeschlossen werden, aber ein Fehler während der globalen Zerstörung) kann das Programm mit einem Exit-Code ungleich Null beenden). Ich weiß auch nicht, ob diese Probleme behoben werden können, aber sie können normalerweise umgangen werden.
Verwenden Sie zunächst eine globale Variable, um festzustellen, ob Sie sich in der globalen Zerstörungsphase befinden:
%Vor% (Siehe auch die ${^GLOBAL_PHASE} Variable in Perl v & gt; = 5.13.7)
Vermeiden Sie es dann, den problematischen Code während der globalen Zerstörungsphase auszuführen:
%Vor%Überprüfen Sie auf alle Typglobs, die auf Zeiger verweisen, z. ein typeglob für einen Hash von Hashes. Ich habe das mit einem type-glob erfahren, mit dem man zwischen verschiedenen Hashes von Arrays wechseln konnte. Der Fehler trat auf, wenn Einträge sowohl mit typeglob als auch mit dem ursprünglichen Hash-Namen gelöscht wurden. Entweder mit einem einfachen Hash ohne Verschachtelung oder ohne den Typglob loszuwerden behebt das Problem.
foreach (@var) ist ein weiterer guter Kandidat für die Inspektion.
Der folgende Code gab mir diese Warnung:
%Vor%Aber das Folgende nicht:
%Vor%