Loxone Config – Debuggen mit picoC und Loxmock

This content has been archived. It may no longer be relevant

Hilfe für die Entkäferung

Fehlersuche kann manchmal richtig anstrengend sein. Wenn es noch dazu dann keine guten Hilfsmittel gibt, kommt schnell Frust auf. Ich habe picoC mal einen einfachen Debugger spendiert. Heißt: Anzeige von Heapinformationen und Haltepunkte im Code sind jetzt möglich. Dazu ist mindestens picoc4lm v04.4 notwendig.

Update: Zusammenfassung aller Loxmock Features, aller Möglichkeiten zum Debuggen und den aktuellsten Stand gibts hier. Nur dort werden weitere Updates gepflegt.

Bei der Verwendung von Loxmock für die Skript-Entwicklung für meine Loxone-Umgebung wollte ich noch mehr Möglichkeiten zur Fehlersuche haben. Diese möchte ich Euch nicht vorenthalten. Also was gibts?

Features des Debugger

Die nun beschriebenen Punkte sind im darauffolgenden großen Bild dargestellt. Damit bekommt man einen guten Eindruck, wie das aussehen kann. Also, was gibts?

• Heap-Tracker: Man kann sich die allokierten Pointer anzeigen lassen inkl. der Zeilenangabe im Skript, wo der Pointer allokiert wurde. Wird also ein free() vergessen, so bleibt der Pointer auf dem Heap. Bei vielen Iterationen wächst dieser an und sieht dann doch sehr auffällig in der Heapanzeige aus. Dieses Feature gibts leider nur in der Linux-Variante.

• Breakpoints: Man kann Haltepunkte im Skript setzen. Hat man sein Skript vor Augen und setzt an einer bestimmten Zeile einen Haltepunkt, so wird automatisch unterbrochen. Gerade bei Iterationen, kann man so kontrolliert fortsetzen, bis man z.B. eine bestimmte Menge an Durchläufen erreicht hat.
• Steuerung während der lokalen Ausführung über folgende Tastenkombinationen:

Bei einer Unterbrechung bekommt man eine kleine Commandline mitsamt einer Hilfeanzeige:

• Werteänderungen zur Laufzeit: Bei Unterbrechungen mittels Ctrl+C können beliebige picoC Kommandos aufgerufen werden. Also z.B. getinput(); oder alles was man sich so denken kann. Für Werteänderungen von hartcodierten Daten stellt Loxmock folgende Funktionen zur Verfügung. Arbeitet der Loxmock mit Livedaten direkt von Loxone und/oder echtem Netzwerk, dann reichen natürlich die entsprechenden getter-Aufrufe.

              lm_setinputtext(0, ""); // Kanal, Wert
              lm_setinput(0,  0, ""); // Kanal, Wert, "ggfls. Name Loxone Objekt"
              lm_set_httpget("");
              lm_set_result_stream("");
              lm_set_localwebservice("");
              lm_setinputevent("0000000000000000");
              setio("VI1", 3.1415);

Nun zur Darstellung. Man sieht die Konsolenausgabe chronologisch von oben nach unten. Nach 3 Iterationen des Skriptcodes(rechts im Bild) unterbreche ich mit Ctrl+C und gebe den Heap aus. Danach setze ich einen Breakpoint, setze fort und bekomme an der gewünschten Stelle meinen Interrupt. Man sieht an der blauen Markierung die nach 3 Iterationen entstandenen 3 Leaks.

Der Härtetest besteht natürlich im längeren Dauerlauf der Schleifen. Man kann dann unterbrechen und die Heapentwicklung betrachten oder das Ganze „von außen“ wie folgt anschauen.

Memoryleaks

Das Verhalten des loxmock ist bzgl. der Speicherallokation wie die Loxonefunktionen. Bei Aufrufen von z.B. getinputtext() oder anderen Funktionen mit entsprechenden Rückgabezeigern werden Werte zurückgeliefert, die mittels free() auch wieder freigegeben werden müssen. Erfolgt das nicht, folgt irgendwann die Quittung. Selbst verschuldete Leaks haben natürlich den gleichen Effekt. Wird alles nur oft genug wiederholt, steigt das Programm irgendwann eben aus. Man sieht das unter Windows recht schön im Taskmanager. Startet man das picoC Skript und wartet auch nicht bei den sleep-Statements, werden viele Iterationen in kurzer Zeit durchgeführt. Steigt der Ressourcenverbrauch kontinuierlich, so empfehle ich von einem Produktionsdeployment abzusehen… 😉

Achtung bei Windows: Das ausführende picoc-Programm wird wirklich als picoc.exe angezeigt und ist nicht zu verwecheln mit der „Windows-Befehlsprozessor“ oder „cmd.exe“ o.ä. Anzeige.

Entsprechende Anzeigen gibts unter den anderen Betriebssystemen natürlich auch.

Zum Testen einfach mal 10 Minuten laufen lassen und beobachten. Ein zurückgegebener Leerstring "" enthält 1 Byte. Dauert also, aber irgendwann…

#ifdef LOXMOCK
    #include "loxmock.c"
#endif
while (TRUE) {
    char *cleverInput = getinputtext(0);
    // Ooops, forgot to free(cleverInput);
}

Und was ist mit dem Download?

Der Download von picoc4lm ist hier verfügbar.

Um Arbeit zu sparen ist hier noch der Demo-Leak Code aus dem Screenshot.

Wie immer gilt: Fortschritt, nicht Perfektion… Feedback ist also jederzeit willkommen.