Letzte Woche, bevor ich am Donnerstag ins Wochenende verreist bin, war noch alles in Ordnung.
Nach meiner Rückkehr finde ich jede Menge dieser Meldungen
2015.10.04 21:24:03 1: memGzip: Wide character in memGzip at ./FHEM/01_FHEMWEB.pm line 449
im Logfile und die Auslieferung einiger InfoPanel-Seiten funktioniert nicht mehr.
Da ich - wie gesagt - in der Zwischenzeit nicht zuhause war, hat sich an meinem fhem in der Zeit auch definitiv nichts verändert.
Die Meldung führt offenbar auch regelmäßig zum kompletten Absturz von fhem, da es immer die letzte Meldung im Log ist, bevor ich dort einen Neustart finde. :(
Nachtrag: Es gibt in diesem Zusammenhang noch eine zweite - ähnliche Meldung - im Logfile:
Wide character in syswrite at fhem.pl line 664.
Nach dieser Meldung stürzt fhem dann definitiv ab.
Irgendein Modul schleust UTF-8 Daten in FHEM ein.
ja... die Tagesschau...*grummel*
Trotzdem bleibt die Frage, ob/wie man sowas in fhem abfangen könnte.
Testweise hatte ich in der fhem.pl die Zeile
my $ret = syswrite($hash->{CD}, $wb);
in
my $ret = syswrite($hash->{CD}, encode("utf8",$wb));
geändert, dann gab es erstmal keine Fehlermeldung und keine Abstürze mehr. Das Ergebnis sah dann zwar nicht 100% so aus, wie ich mir das dachte, aber die Änderung hat mich zumindest auf die Spur des Verursachers geführt.
Vielleicht könnte man zumindest um das syswrite() ein eval bauen, damit fhem nicht komplett abstürzt.
Tagesschau? Bahnhof?
Bist du sicher, dass ein eval hilft? Ich meine das haben wir beim letzten Mal versucht, und es hat nicht geholfen.
Tagesschau: Ich nutze den RSS Feed der Tagesschau, um Nachrichtenschlagzeilen in einem Ticker in einigen meiner InfoPanel devices anzuzeigen. Seit dem Wochenende müssen in diesem Feed merkwürdige Zeichen vorkommen (oder man hat das Encoding des Feeds geändert) die in fhem dann zum beschriebenen Problem führen.
Ob ein eval hilft? Ich habs noch nicht getestet, aber ich kann das ja gleich mal ausprobieren.
ok, ich habs getestet.
Die betreffende Stelle in der fhem.pl ad-hoc so geändert:
my $ret = "";
eval { $ret = syswrite($hash->{CD}, $wb); };
Es wird dann beim Vorkommen von UTF8-Zeichen zwar kein verwertbarer Inhalt an den Browser geliefert, aber zumindest stürzt fhem nicht mehr komplett ab.
Man kann das natürlich noch "schön" machen, mit Log und so, aber mir ging es erstmal um die prinzipielle Funktion.
Hi betateilchen,
danke für den "fix".
Hatte gestern auch die tagesschau-function im visier, die mir etliche Abstürze erzeugt hatte bzw. gar nix zur Ausgabe brachte.
Da jetzt beim Tablet-ui-Aufruf des tagesschau-outputs fhem komplett noch abgestürzt ist, war das wohl aufgrund eines nicht-utf8-Zeichens.
Jedenfalls funktioniert's jetzt wieder.
Grüße!
Zitat von: knopf_piano am 05 Oktober 2015, 20:52:30
Jedenfalls funktioniert's jetzt wieder.
ja, heute sind die Tagesschau-Feeds wieder in Ordnung und enthalten keine "verbotenen" Zeichen mehr.
hm,
doch nicht ganz,
ein anderer feed liefert
Nach dem Fasching geht's rund
da verschluckt sich fhem auch wieder und ich krieg im log
setreading newsIngolstadt2Readings feed_17 Nach dem Fasching geht's rund : Cannot open /media/infrastruct_server/fhem/my_fhem_cfg.cfg: Keine Berechtigung, ignoring its content
...
:-\
Was ich jetzt gemacht hab in der News-funktion, das Zeichen ''' erstmal zu ersetzen
$h =~s /'/'/g;
--> geht.
Aber nur punktuelle abhilfe. Das nächste Sonderzeichen droht :o
Mein Versuch in 99_myUtils.pm mit
use HTML::Entities;
...
decode_entities($h);
führt in fhem nicht zum Erfolg, obwohl der offline-testcode das tut, was es soll
#!/usr/bin/perl
use strict;
use warnings;
use HTML::Entities;
my $str = 'Nach dem Fasching geht's rund';
decode_entities($str);
exit 0;
Idee?
Zitat von: knopf_piano am 07 Oktober 2015, 11:48:11
Mein Versuch in 99_myUtils.pm mit
führt in fhem nicht zum Erfolg,
Das funktioniert grundsätzlich schon, das Problem dabei ist, dass dann trotdem ein utf8 an fhem zurückgeliefert wird, was man auch im Log sieht, wenn man versucht, das Ergebnis im fhem Frontend darzustellen:
2015.10.07 13:57:33 1: PERL WARNING: Wide character in print at fhem.pl line 820.
2015.10.07 13:57:33 1: DEBUG>Nach dem Fasching geht's rund
:-\
hatt mal ein Projekt, aus der kette html -> xml -> pl -> xls/pdflatex.
Da hatt ich auch mit sowas gekämpft...
Das heutige update der fhem.pl hat meinen hier im System eingebauten Patch wieder zunichte gemacht 8)
Zitat von: betateilchen am 04 Oktober 2015, 23:20:00
ok, ich habs getestet.
Die betreffende Stelle in der fhem.pl ad-hoc so geändert:
my $ret = "";
eval { $ret = syswrite($hash->{CD}, $wb); };
Jep, ist mir im svn schon aufgefallen, daher hab ich kein update gemacht :-)
Meine Hoffnung, dass Rudi die vorgeschlagene Änderung irgendwann doch noch in die fhem.pl übernimmt, habe ich noch nicht ganz aufgegeben 8)
Ich habs eingecheckt, mit zusaetzlichen Log, falls was schiefgeht.
Ich hatte gezoegert, da ich befuerchtete, dass ein zentrales eval auf langsamen Systemen zu merkbaren Slowdown fuehrt. Allerdings wird dieses syswrite nicht so haeufig aufgerufen, und ein Test auf einem Fritzbox (das langsamste, was ich mit perl auftreiben konnte) zeigt, dass eval wenig Zusatzkosten bedeutet (etwa 4s fuer eine Million Aufrufe).
Zitat von: rudolfkoenig am 10 Oktober 2015, 18:30:37
Ich habs eingecheckt, mit zusaetzlichen Log, falls was schiefgeht.
Danke!
Zitat von: rudolfkoenig am 10 Oktober 2015, 18:30:37
dass eval wenig Zusatzkosten bedeutet (etwa 4s fuer eine Million Aufrufe).
Damit sollte man leben können :)
Auch danke!
Gesendet von meinem GT-I9301I mit Tapatalk