PERL WARNING: Prototype mismatch: sub main::ctime

Begonnen von Mario67, 13 März 2021, 23:26:11

Vorheriges Thema - Nächstes Thema

Mario67

Hallo,

seit einigen Tagen habe ich bei meinem System immer wieder einen Absturz. Im Log steht jeweils:

:
2021.03.08 18:22:37 1: PERL WARNING: Prototype mismatch: sub main::ctime: none vs (;$) at /usr/share/perl/5.24/Exporter.pm line 66.
:
:
2021.03.08 18:22:40 1: PERL WARNING: Prototype mismatch: sub main::ctime (;$) vs none at ./FHEM/90_at.pm line 7.
:

Aus den zuvor laufenden Ereignissen im Log lässt sich kein Muster erkennen.
Ein  Update hat leider auch nicht geholfen.
Ich habe die Diskussionen in

Revision 21510: use POSIX: delete this in some modules; small changes in attrTemplate files
https://forum.fhem.de/index.php/topic,109512.msg1034919.html#msg1034919

"use POSIX" aus einem Modul werfen - Beispiel WeekdayTimer
https://forum.fhem.de/index.php/topic,109509.msg1034932.html#msg1034932

FHEM mit Perl 5.24.1
https://forum.fhem.de/index.php/topic,72085.msg636859.html#msg636859

gelesen.
In 99_at.pm ist noch ein
use POSIX;
vorhanden.

Ich bin ein wenig ratlos. Hat jemand eine Idee zur Fehlersuche?

Danke,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

Beta-User

Na ja, das Warning ist ein Warning und sollte nicht für einen Absturz gut sein.

Evtl. mal stacktrace einschalten, um die wahre Ursache zu finden?

Prinzipiell sollte "use POSIX;" in 90_at.pm überflüssig sein, nicht mehr und nicht weniger war eigentlich die Botschaft aus dem verlinkten WDT-Thread  (in dem Zuge ist es z.B. auch aus der myUtils-template-file geflogen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

ZitatPrinzipiell sollte "use POSIX;" in 90_at.pm überflüssig sein
Stimmt, den habe ich jetzt auch entfernt.
Sollte aber keine Auswirkung haben, da "use POSIX;" auch in fhem.pl vorkommt.
Da wuerde ich diese Zeile auch gerne rausschmeissen, fuerchte mich aber noch von den Nachwirkungen.

Beta-User

Na ja, ob es dort (in fhem.pl) überflüssig ist, kann ich nicht sagen. Mein möglicherweise begrenztes Verständnis war: fhem.pl importiert es, also muss kein Modul, das ebenfalls im main-namespace angesiedelt ist, das nochmal tun. Und solange es irgendeines tut (dieses "use"), wird auch nichts passieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

ZitatNa ja, ob es dort (in fhem.pl) überflüssig ist, kann ich nicht sagen.
Statt ueberfluessig wuerde ich unvorsichtig sagen.
"use POSIX" holt eine Riesentuete von diskussionswuerdigen Funktionen rein, man sollte mAn alle Funktionen einzeln importieren. Wenn ich aber "use POSIX" jetzt aus fhem.pl entferne oder es auf von fhem.pl verwendeten Funktionen begrenze, werden vmtl. viele Module nicht mehr laufen.

Beta-User

Zitat von: rudolfkoenig am 14 März 2021, 11:07:10
"use POSIX" holt eine Riesentuete von diskussionswuerdigen Funktionen rein, man sollte [...]
Bin wie gesagt da nicht der Experte, aber  bevor man es aus fhem.pl ausbaut bzw. auf die wirklich verwendeten Funktionen begrenzt:
Sollte man nicht erst mal die Module ansehen, die heute genau diesen Weg gehen und "use POSIX;" (in main!) anweisen?
Ich zähle via grep in meinem Testsystem ca. 85-90 Module allein aus ./FHEM, die an der Stelle dasselbe "unvorsichtigerweise" tun, wie bisher at... (Und wenn eines dann tatsächlich (!) eine Funktion aus POSIX verwendet (was bei "meinen" bisher wenn, dann nur indirekt der Fall war): Was dann? Import nach main, oder doch lieber irgendeine andere Methodik? Jedenfalls auf die Schnelle fällt mir keine wirklich überzeugende Lösung ein.)

Ist hier aber m.E. auch die falsche Stelle, um das zu diskutieren, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Mario67

Danke für den Hinweis auf stacktrace. Ich schaue heute Abend mal ob ich mehr heraus bekomme.

Grüße,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich