Fehlermeldung memGzip: Wide character in memGzip

[androsch]

Hallo,

habe seit ein paar Tagen immer wieder mal die o.g. Meldung im Log und wollte wissen, ob das problematisch ist bzw. was ich da tun kann?

Zudem fällt mir zusammen mit der Meldung auf, daß meine Weboberfläche dann komplett leer bleibt, also irgendwas bleibt da anscheinend in dem Zusammenhang hängen, nach einer Weile gehts aber dann wieder....

Mittels Suche hatte ich herausgefunden, daß mein FHEM anscheinend kein GZIP-Modul hatte (Pine64), mittels CPAN nachinstalliert, hat aber nichts geholfen, Meldung ist wieder da und mein FHEM hängt (Oberfläche bleibt weiss)

[dev0]

Ich vermute, dass ein Modul ein nicht erlaubtes, erwartetes oder falsch kodiertes Zeichen an FHEM übergibt. Globales Logging hochdrehen und versuchen das Modul zu identifizieren. Kandidaten könnten Module sein, die Daten aus externen Quellen beziehen (z.B. RSS). Die vollständige Fehlermeldung könnte auch weiterhelfen.

[Benni]

z.B. RSS

RSS erzeugt einen (grafischen) RSS-Feed in FHEM, bspw. für die Anzeige auf einem Tablet.

Du meinst wahrscheinlich rssFeed. Das behandelt das aber bereits korrekt: gezippte Streams werden automatisch erkannt und behandelt. Bei wideCharacter-Problemen muss evtl. noch das Attribut rfEncode auf utf8 gesetzt werden, was aber seit ein paar Versionen bereits per default beim erstmaligen Erstellen des Device so gesetzt wird.

[dev0]

Du meinst wahrscheinlich rssFeed.

Yepp 

[androsch]

Hallo,

habe nach mehreren Versuchen herausgefunden, daß es an meiner Definition im DBPlan lag. Komischerweise nimmt er da eine Verbindung nach Durach (mein Wohnort) nicht mehr an nach einem Update der Daten. Beim ersten Mal geht es noch, nach dem Update bleibt die Seite entsprechend weiss. Bin jetzt auf die nächstgrößere Stadt gewechselt (Kempten), seitdem läufts. Komische Sache... 

[rudolfkoenig]

Ich habe jetzt in die Module telnet und FHEMWEB eine Pruefung auf Wide character eingebaut:

Code Auswählen Erweitern

utf8::encode($ret) if(utf8::is_utf8($ret));
die solche Abstuerze verhindern sollte. Habs kurz getestet, und es wirkt bei mir. Nebeneffekte, die ich kenne:
- funktioniert erst ab perl 5.8.1 (Release Date war vor 13 Jahren)
- Falls auf einer "vergifteten" Seite auch andere Umlaute vorhanden sind, dann sind diese jetzt kaputt, und der Uebeltaeter ist "richtig" zu sehen. Etwas unintuitiv: es muss dann nicht das gefixt werden, was kaputt ausschaut, sondern das Andere.

[androsch]

Hallo,

danke dafür, wie komme ich an die aktualisierte Version, im Updatecheck zeigt er (noch?) nichts an?

Werde dann nochmal die fehleranfällige Verbindung einbauen, vielleicht kommt dann ja noch was anderes raus. Momentan läuft es ja auch ohne den Patch wieder, ich verstehe auch nicht wieso er bei der einen Verbindungsangabe im DBPlan so zickt...

Danke

[rudolfkoenig]

danke dafür, wie komme ich an die aktualisierte Version, im Updatecheck zeigt er (noch?) nichts an?

Manuell aus SVN oder morgen ab 8 per update.

[androsch]

Alles klar, Danke, dann gedulde ich mich einfach noch ein wenig.... 

[androsch]

Kurze Rückmeldung meinerseits, seit Update heute morgen läuft die betroffene Readinggroup und das DBPlan Device problemlos....

Danke!

Gesendet von meinem XT1032 mit Tapatalk

[betateilchen]

- Falls auf einer "vergifteten" Seite auch andere Umlaute vorhanden sind, dann sind diese jetzt kaputt, und der Uebeltaeter ist "richtig" zu sehen. Etwas unintuitiv: es muss dann nicht das gefixt werden, was kaputt ausschaut, sondern das Andere.

*grummel*

Es soll Entwickler geben, die das, was Du jetzt endlich in Deinem FHEMWEB eingebaut hast, schon sehr lange in ihren eigenen Modulen berücksichtigt haben, was dazu führt, dass Deine Änderung dort jetzt gnadenlos scheitert.

Es wäre doch schön, wenn Du solche Änderungen im Vorfeld rechtzeitig unter "Ankündigungenen" ankündigen würdest (deshalb heißt der Bereich so...), damit man als Entwicklerkollege Zeit hat, sich darauf vorzubereiten.

[rudolfkoenig]

Zu den Emotionen (aka *grummel*):
Selbst wenn ich es angekuendigt haette, dass es potentiell unbekannte Nebeneffekte haben koennte (wovon ich nicht ueberzeugt war): was haette das in deinem Fall fuer ein Unterschied gemacht? Ich brauche Feedback. Wer beim debuggen nicht helfen (vulgo keinen Aerger)  will, der soll nicht updaten. Wer FHEM produktiv hat, der soll, wie in der Produktion ueblich, vor dem Software-Upgrade tests machen.

Zu der Sache:
ich pruefe per is_utf8, ob ein String wide character hat. encode loescht diesen Flag. Nach meiner Theorie kann nur dann Muell entstehen, wenn es sonst zu einem Absturz gekommen waere. Falls ich sachdienliche Hinweise kriege, werde ich das Problem angehen.

[viegener]

Ich habe mich auch ein wenig mit is_utf8 beschäftigt und meinem Verständnis nach wird dabei nur überprüft ob perl den String intern als utf8-encoded markiert hat, nicht unbedingt, ob darin wide chars enthalten sind (siehe auch alte Threads zu dem Thema https://forum.fhem.de/index.php/topic,54196.msg463395.html#msg463395).

Ich habe keine zufriedenstellende Lösung gefunden, nur eine die offensichtlich über die verschiedenen perl-Versionen, die sich unterschiedlich verhalten korrekt verhält. Es gibt offensichtlich Fälle, wo Strings intern als utf8 markiert sind, dann aber durch einen encode auf bestimmten Rechnern/Installationen umkodiert werden. Ich habe deshalb bei mir für entsprechende Strings (bei mir kommen sie aus der JSON-konvertierung) folgende Codestücke einfügen müssen:

Code Auswählen Erweitern

  if ( utf8::is_utf8($ret) ) {
    utf8::downgrade($ret);
  }


Mir behagt das zwar nicht, es löst aber die Probleme, dass ansonsten utf8-Zeichen wieder als latin-Zeichen umkodiert werden. Aus meienr Sicht handelt es sich hier eigentlich um perl-Fehler und zwar nicht das erste mal, wenn es um unicode geht.

Achso, es geht auch bei mir um texte, die unicode-Zeichen enthalten.

[rudolfkoenig]

Ich habe dazu auch meine Theorie bzw. Loesung, siehe https://forum.fhem.de/index.php/topic,55539.msg471516.html#msg471516

[viegener]

Ja das deckt sich mit meinen vermutungen, denn das utf8-flag scheint wirklich eine gewisse unabhängigkeit von wirklich vorhandenen mehrbytezeichen zu sein und gesetzt zu bleiben, selbst wenn durch string operationen, keine mehrbytigen unicodezeichen enthalten sind. Nur durch downgrade wird man es wieder los, ohne gefahr irgendeiner konvertierung.

Problem ist aus meiner sicht, dass die versionen und varianten sich wohl unterschiedlich verhalten. Mein verdacht ist speziell hier die json-modules.