Autor Thema: readingsGroup crashed FHEM reproduzierbar!  (Gelesen 682 mal)

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
readingsGroup crashed FHEM reproduzierbar!
« am: 22 Oktober 2017, 20:23:20 »
Und das geht so:
  • Man nehme einen Server mit Ubuntu 17.10 (richtig, die neueste Version!), womit man dann auch Perl 5.26.0 hat.
  • Man folge dieser Wiki-Anleitung: https://wiki.fhem.de/wiki/ReadingsGroup#Readings_aus_zus.C3.A4tzlichen_Devices und erstelle eine ReadingsGroup mit Werten aus min. 2 Devices
  • Nur zur Analyse: man beobachtet das FHEM.log während man die FHEM-Seite mit der Redings-Group aufruft: tail -f fhem-2017-10.log

Ergebnis des Logs:
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/^desired-temp@{ <-- HERE valveOfDevice($DEVICE)}$/ at ./FHEM/33_readingsGroup.pm line 1383.
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/opt/yowsup/yowsup/demos/cli/cli.py", line 153, in startInputThread
    cmd = self._queuedCmds.pop(0) if len(self._queuedCmds) else input(self.getPrompt()).strip()
EOFError: EOF when reading a line

Traceback (most recent call last):
  File "/opt/yowsup/yowsup-cli", line 368, in <module>
    if not parser.process():
  File "/opt/yowsup/yowsup-cli", line 268, in process
    self.startCmdline()
  File "/opt/yowsup/yowsup-cli", line 297, in startCmdline
    stack.start()
  File "/opt/yowsup/yowsup/demos/cli/stack.py", line 26, in start
    self.stack.loop(timeout = 0.5, discrete = 0.5)
  File "/opt/yowsup/yowsup/stacks/yowstack.py", line 188, in loop
    asyncore.loop(*args, **kwargs)
  File "/usr/lib/python2.7/asyncore.py", line 216, in loop
    poll_fun(timeout, map)
  File "/usr/lib/python2.7/asyncore.py", line 156, in poll
    read(obj)
  File "/usr/lib/python2.7/asyncore.py", line 87, in read
    obj.handle_error()
  File "/usr/lib/python2.7/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/usr/lib/python2.7/asyncore.py", line 449, in handle_read_event
    self.handle_read()
  File "/opt/yowsup/yowsup/layers/network/layer.py", line 102, in handle_read
    self.receive(data)
  File "/opt/yowsup/yowsup/layers/network/layer.py", line 110, in receive
    self.toUpper(data)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/stanzaregulator/layer.py", line 29, in receive
    self.processReceived()
  File "/opt/yowsup/yowsup/layers/stanzaregulator/layer.py", line 49, in processReceived
    self.toUpper(oneMessageData)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/auth/layer_crypt.py", line 65, in receive
    self.toUpper(payload)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/coder/layer.py", line 35, in receive
    self.toUpper(node)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/logger/layer.py", line 14, in receive
    self.toUpper(data)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/axolotl/layer_control.py", line 44, in receive
    self.toUpper(protocolTreeNode)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 194, in receive
    s.receive(data)
  File "/opt/yowsup/yowsup/layers/axolotl/layer_receive.py", line 44, in receive
    self.toUpper(protocolTreeNode)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 194, in receive
    s.receive(data)
  File "/opt/yowsup/yowsup/layers/__init__.py", line 126, in receive
    if not self.processIqRegistry(node):
  File "/opt/yowsup/yowsup/layers/__init__.py", line 161, in processIqRegistry
    successClbk(protocolTreeNode, originalIq)
  File "/opt/yowsup/yowsup/layers/protocol_iq/layer.py", line 30, in onPong
    self.toUpper(ResultIqProtocolEntity.fromProtocolTreeNode(protocolTreeNode))
  File "/opt/yowsup/yowsup/layers/__init__.py", line 79, in toUpper
    self.__upper.receive(data)
  File "/opt/yowsup/yowsup/layers/interface/interface.py", line 80, in receive
    self.entity_callbacks[entityType](entity)
  File "/opt/yowsup/yowsup/demos/cli/layer.py", line 458, in onIq
    print(entity)
IOError: [Errno 32] Broken pipe

Weitere Informationen:
Meiner Meinung nach ist das Problem das gleiche, wie bereits hier beschrieben wurde https://forum.fhem.de/index.php/topic,71402.0.html, mit dem Unterschied, dass aus der Warnung in der neuen Perl-Version jetzt ein harter Crash geworden ist. Allerdings bin ich kein Perl-Entwickler und somit ausserstande das abschließend zu beurteilen.

Ein Hinweis, der diese These stützt findet sich aber auf der Perl-Seite https://metacpan.org/pod/distribution/perl/pod/perldeprecation.pod#Unescaped-left-braces-in-regular-expressions:

Literal uses of { were deprecated in Perl 5.20, and some uses of it started to give deprecation warnings since. These cases were made fatal in Perl 5.26.

Kann mir irgend jemand einen Workaround/Lösung nennen?
Ist das Wiki falsch/muss es überarbeitet werden?
Ist das tatsächlich ein Bug in 33_readingsGroup.pm? Falls ja, wie kann ich einen Bug-Report machen?


Ich wäre wirklich für jeden Hinweis dankbar!

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17761
Antw:readingsGroup crashed FHEM reproduzierbar!
« Antwort #1 am: 12 Februar 2018, 13:22:36 »
sorry das es etwas länger gedauert hat...

bitte teste mal die angehängte version.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline aiola

  • Newbie
  • Beiträge: 2
Antw:readingsGroup crashed FHEM reproduzierbar!
« Antwort #2 am: 23 April 2018, 00:01:52 »
Bin gerade selber über das Problem gestolpert und auch die neue Datei bringt keine Veränderung.

Offline sfancy

  • New Member
  • *
  • Beiträge: 13
Antw:readingsGroup crashed FHEM reproduzierbar!
« Antwort #3 am: 01 Mai 2018, 08:30:32 »
Na die fehlschlagende Stelle ist ja bei allen "at ./FHEM/33_readingsGroup.pm line 1383".

In Zeile 1383 steht
next if( defined($regex) && $reading !~ m/^$regex$/);Wenn jetzt in $regex z.B. controlMode@{$DEVICE.'_Clima'} steht, dann kommt die obige Fehlermeldung.

Weshalb wird an der Stelle überhaupt ein Regex verwendet? Meiner Meinung nach ist
next if( defined($regex) && $reading ne $regex);equivalent zu
next if( defined($regex) && $reading !~ m/^$regex$/);Mit dem Unterschied, dass es auch in neuen Perl-Versionen fehlerfrei läuft.

Testet das mal ohne Gewähr. Leider ist die Funktion readingsGroup_Notify($$) in der die fehlerhafte Zeile steht ziemlich lang und unübersichtlich, so dass ich nicht alles umrissen habe.
« Letzte Änderung: 01 Mai 2018, 08:40:04 von sfancy »

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
Antw:readingsGroup crashed FHEM reproduzierbar!
« Antwort #4 am: 09 Juli 2018, 18:36:34 »
sorry das es etwas länger gedauert hat...

Na, Du bist ja 'ne Knalltüte...
Dafür, dass ich Dir das Problem bereits am 1. Mai 2017(!!) zum ersten Mal beschrieben habe, ist das eine "kleine" Untertreibung...

Wenn es denn wenigstens jetzt gehen würde! Aber wie aiola schon am 23.4. schrieb: keine Veränderung!
Und sfancy hat Dir am 1.5. eine mögliche Lösung präsentiert. Warum implementierst Du die nicht?

Hör mal, jetzt im Ernst, ein Bug im Code, der das ganze System hart an die Wand fährt ist echt ein Unding! Und vielleicht hast Du den Eindruck, dass das nicht viele betrifft (wobei ich mir da mal nicht so sicher wäre... bei der Komplexität einer ReadingsGroup würde jeder wahrscheinlich den Fehler zuerst bei sich suchen und irgendwann entnervt aufgeben, anstatt an einen Fehler im Modul zu denken, die Dunkelziffer dürfte also entsprechend hoch sein!), aber solange im Wiki ein Beispiel beschrieben wird, wie man Readings aus verschiedenen Devices in einer Zeile darstellt und genau dieses Beispiel dann die ganze FHEM-Installation an die Wand fährt, ist es schon eine gewaltige Ignoranz sich über 1 geschlagenes Jahr Zeit zu lassen, den Fehler zu beheben. Oder gibt es eine andere funktionierende Möglichkeit, mehrere Readings in einer Zeile darzustellen? Dann ändere bitte das Wiki!

Also, nichts für ungut, aber wann können wir endlich mit einer Lösung rechnen???