Gestern haben wir bei der Fertigstellung einiger unserer AMPS Einheiten mit Display und Qt-Applikation einen Fehler festgestellt, der dazu geführt hat, dass die Anwendung in seltenen Fällen nicht korrekt gestartet werden kann und crasht. Der Fehler sieht wie folgt aus:

Wie bereits in früheren Blogposts erwähnt, nutzen wir innerhalb einer Qt Quick Anwendung die Chromium-basierte Qt WebEngine, um Webinhalte darstellen zu lassen. Im Laufe der Entwicklung haben wir allerdings einen unerfreulichen Bug entdeckt, der unsere Anwendung nach einiger Zeit im laufenden Betrieb abstürzen lässt. Zunächst friert das Web-Fenster ein - etwas später folgt dann der Rest der Anwendung, bis die Anwendung schließlich beendet wird.

In diesem Beitrag stellen wir einen Workaround vor, der für uns funktioniert hat.

Während der Entwicklung einer Qt-basierten Anwendung auf einem Raspberry Pi 4 (CM) sind wir von der ZERO GmbH vor ein paar Tagen auf ein kurioses Problem gestoßen: Die Anwendung beinhaltet zwei Anwendungsfenster - ein QT Quick Fenster und ein weiteres Fenster, das mittels WebEngine (Chromium) eine Webanwendung darstellt. Die Inhalte in beiden Fenstern wurden während des Debuggings und beim manuellen Starten der Binärdatei aus der Kommandozeile heraus flüssig dargestellt. Bei Animationen und Mausbewegungen konnten wir keine bemerkenswerten Ruckler feststellen.

Beim Kompilieren von Qt 5.15.2 aus den offiziellen Open Source Quellen sind wir in Kombination mit unserem Buildserver auf ein Problem getoßen: Der Buildprozess wurde beim Kompilieren der Chromium-basierten “WebEngine” Komponente mit zunächst mysteriösen Fehlermeldungen unterbrochen. Ein Blick in das Kernellog mittels dmesg -w offenbarte dann schnell, dass der sog. OOM-Killer des Linux-Kernels zugeschlagen hatte. Offenbar war der RAM-Verbrauch des Buildprozesses so speicherintensiv, dass der Prozess abgebrochen werden musste, um das Betriebssystem lauffähig zu halten.