Webserver reagiert nicht mehr - EibPC läuft jedoch...

[klaus_kraemer]

Selten, aber doch so einmal die Woche ist bei mir z.Zt. der Webserver nicht erreichbar. Gerade ist es so und ich dachte mir, mal der Sache auf den Grund zu gehen. Allerdings kann ich nichts finden.

• Im Ereignisspeicher ist zwar massig was an Meldungen vorhanden, das hat jedoch mit dem "ERR_DIVISION_BY_ZERO"-Problem zu tun, das ja auch bei vorher "abgefangenen" Divisionen durch 0 leider zuschlägt.
• nconf gibt meiner Meinung nach auch nichts her, was verlangt, dass der Webserver seinen Dienst einstellt:
  
  Firmwareversion des EibPCs: v3.019
  Seriennummer des EibPCs: 00000422
  Netzwerkeinstellungen: DHCP
  Netzmaske: 255.255.255.0
  Gateway: 192.168.0.1
  Nameserver 1: 192.168.0.1
  Nameserver 2: ?
  Nameserver 3: ?
  Physikalische Adresse: 00-50-c2-79-31-6f
  Patches:
  3.019.ptc
  Boot image:
  Boot image fixes: 0
  Boot image updates: 3
  System boot time: Sat Jul 11 17:52:43 CEST 2015
  Average CPU usage since booting: 59 %
  Maximum available firmware memory: 11144 kb
  Telegram buffer reduced to: 250000
  VPN: The openvpn daemon is not running.
  Allowed VPN users:
  Drücken Sie eine beliebige Taste . . .

Das Verhalten beobachte ich nun, seit ich ein paar massivere Strings zusammenbastele. Wenn ich diese Strings im EibStudio abfrage, wird nicht nur der erwartete Inhalt angezeigt, sondern auch Garbage, der aussieht wie ein Problem bei der Speicherbelegung:


Auf jeden Fall weiß ich derzeit nicht, wo ich wirklich ansetzen kann. Gibt der Webserver wenigstens irgendwelche Ereignisse aus, wenn er sich aus irgendwelchen Gründen regulär verabschiedet?

[enertegus]

S
Telegram buffer reduced to: 250000

Dein EibPC ist speichemäßig zumindest schon mal an eine Warn-Grenze gestoßen, daher wurde der Telegrammspeicher schon mal halbiert.

Auf jeden Fall weiß ich derzeit nicht, wo ich wirklich ansetzen kann. Gibt der Webserver wenigstens irgendwelche Ereignisse aus, wenn er sich aus irgendwelchen Gründen regulär verabschiedet?

Nein, das Linux macht bei Speicherknappheit Prozesse dicht, da hat der Webserver gar keine Möglichkeit, sich zu melden. Die FW verkleinert den Telegrammpuffrer, um Speicher freizugeben. Vielleicht müssen wir hier nochmal etwas an der eingestellten Grenze feilen.

Das Verhalten beobachte ich nun, seit ich ein paar massivere Strings zusammenbastele. Wenn ich diese Strings im EibStudio abfrage, wird nicht nur der erwartete Inhalt angezeigt, sondern auch Garbage, der aussieht wie ein Problem bei der Speicherbelegung:

Die Abfrage von Strings und die Kommunikation/Debugging braucht dann natürlich nochmehr Speicher.
Deine Aussage ist zu wage, als dass ich hier mir was wie "Garbage" vorstellen kann. Da bräuchte ich schon ein nachvollziehbares Beispiel.

[klaus_kraemer]

...
Deine Aussage ist zu wage, als dass ich hier mir was wie "Garbage" vorstellen kann. Da bräuchte ich schon ein nachvollziehbares Beispiel.

Schau bitte mal ins Betaforum, der Screenshot bei den Stringcrashes.

Trotzdem, Webserver steht - aber immer noch 12MB?

[enertegus]

Schau bitte mal ins Betaforum, der Screenshot bei den Stringcrashes.

Eben erst gesehen.

[saft6luck]

Eben erst gesehen.

Da erinnere ich gerne an meinen Beitrag (<- klick) von 2014, den du wohl auch noch nicht gesehen hast.

Denn sonst hättest du bestimmt schon danach gefragt, dass dich jemand zur Lösung trägt.

Gibt es denn inzwischen schon eine Lösung zum "Convert c14 Bug"?

[enertegus]

Gibt es denn inzwischen schon eine Lösung zum "Convert c14 Bug"?

Ja, der ist gefixt im nächsten Release. Deinen Beitrag habe ich nicht auf dem Radar gehabt, ich geb das in die Entwicklung. Könnte ein brauchbarer Hinweis sein

[enertegus]

Ja, der ist gefixt im nächsten Release. Deinen Beitrag habe ich nicht auf dem Radar gehabt, ich geb das in die Entwicklung. Könnte ein brauchbarer Hinweis sein

Wir haben hier was gefunden:

[EibPC]
x=$56$c4
y=$123$c4
z=$$c44
if systemstart() then {
// Erwartungswert: z=$1235$
z=y+x;
}endif

Das Problem ist hier, dass die Stringverkettung nur 4 Byte lang ist, das Ergebnis aber 44 Bytes haben kann. Da wird dann offensichtlich wild aus dem Speicher mitkopiert - man beachte auch den Hinweis zur Verkettung im Handbuch V29 / S.113.
Wird bald gefixt.

[klaus_kraemer]

Wir haben hier was gefunden:

Das Problem ist hier, dass die Stringverkettung nur 4 Byte lang ist, das Ergebnis aber 44 Bytes haben kann. Da wird dann offensichtlich wild aus dem Speicher mitkopiert - man beachte auch den Hinweis zur Verkettung im Handbuch V29 / S.113.
Wird bald gefixt.

[EibPC]
x=$56$c4
y=$123$c4
z=$$c44
if systemstart() then {
// Erwartungswert: z=$1235$[INDENT][COLOR=#008000]z=$$;[/COLOR]
z=[COLOR=#008000]z+[/COLOR]y+x;[/INDENT]
 }endif

Ich habe dem Hinweis auf obenstehende Art (den geleerten Zielstring in die Verkettung mit aufzunehmen) entgegenzuwirken versucht. Gebracht hat's aber nix. Und sobald ich Makros zur Stringbearbeitung einsetze, um z.B. HTML-Code einzubringen, muss ich mich auf die richtige Stringverkettung verlassen können, denn die hier bearbeiteten Stringgrößen variieren natürlich immer - sonst kann ich die Makros auf Dauer wegschmeissen...