readingsGroup crashed FHEM reproduzierbar!

Begonnen von linuzer, 22 Oktober 2017, 20:23:20

Vorheriges Thema - Nächstes Thema

linuzer

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!

justme1968

sorry das es etwas länger gedauert hat...

bitte teste mal die angehängte version.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

aiola

Bin gerade selber über das Problem gestolpert und auch die neue Datei bringt keine Veränderung.

sfancy

#3
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.

linuzer

Zitat von: justme1968 am 12 Februar 2018, 13:22:36
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???