Dringend: Programm hängt in der Konsole - kann ich sehen wo?

[Timm Thaler]

Ich habe einen Telegram-Bot-Client, der auf dem Raspberry Pi 3B unter Raspbian läuft. Normalerweise wird er beim Reboot zeitverzögert gestartet, kontaktiert den Bot und fragt dann regelmäßig, ob Eingaben vorliegen, auf die er dann Daten ausliefert.

Funktioniert soweit. Allerdings "hängt" er sich mitunter auf, sprich, er reagiert nicht mehr auf Eingaben. Wobei ich bisher nicht rausfinden konnte, ob der Client nichts mehr abfragt oder nichts mehr ausliefert. Passiert auch nur sporadisch.

Vor ein paar Tagen hab ich allerdings dran rumgefummelt, und ihn dann direkt in der Konsole gestartet. Das ging bis heute nachmittag gut, jetzt reagiert er wieder nicht mehr. Aber: Er reagiert auch nicht auf Ctrl-C in der Konsole, normalerweise meldet er sich dann ab und das Programm endet. Scheint sich also richtig aufgehängt zu haben.

Nun hab ich das Programm noch in der Konsole liegen: Gibt es eine Möglichkeit herauszufinden, an welcher Stelle das Programm hängt?

Im Taskmanager steht es mit 0% CPU, 5,9MB RSS, 8,1MB Speicher, Status S. Das sind die üblichen Werte, ein Speicherleck scheint es schonmal nicht zu geben. Kompiliert habe ich mit Laz 1.9.0, FPC 3.1.1 per arm-linux Crosscompiler von Windows aus. Jetzt allerdings die schlechte Nachricht: Da per Crosscompiler erstellt, sind sämtliche Debuggereinstellungen ausgeschaltet.

[Mathias]

Gibt es eine Möglichkeit herauszufinden, an welcher Stelle das Programm hängt?

Was willst du, die PID ?

Wen du in einer 2. Konsole "ps a" werden alle deine gestarteten Programm gelistet.
Hilft dir dies weiter ?
Siehe auch: https://wiki.ubuntuusers.de/ps/

[Warf]

Starte den bot mit gdb über kommandozeile in einer screen (oder tmux) Session detached, und sobald du merkst das er hängt reattachen und mit gdb debuggen.

Ansonsten viel logging betreiben und in die logs schauen

[Timm Thaler]

Was willst du, die PID ?

Nee, die steht ja schon im Taskmanager.

Starte den bot mit gdb über kommandozeile in einer screen (oder tmux) Session detached, und sobald du merkst das er hängt reattachen und mit gdb debuggen.

Das nützt mir gerade nichts, wie gesagt läuft er mitunter tage- oder wochenlang problemlos. Jetzt hängt er gerade so schön und ich hätte gern gewusst an welcher Stelle im Programm, bevor ich das Programm abschieße und neustarte.

Gibts nicht sowas wie einen Programmzeiger, der auf den aktuellen Befehl zeigt und den ich von aussen abrufen könnte?

[Mathias]

Das nützt mir gerade nichts, wie gesagt läuft er mitunter tage- oder wochenlang problemlos.

Hast du irgendwelche Timer oder Zeitabfragen eingebaut ?
Vielleicht hast du dort ein Überrlauf und es fängt wieder von vorn an und dies gibt eine Endlosschleife. Dies ist mir mal passiert. der PC lief mal über Mitternacht und da hat es wider bei 0 begonnen.

Gibts nicht sowas wie einen Programmzeiger,

Ein Logfile einbauen ?

[Warf]

Dein Problem klingt übrigens nach einem Deadlock. Also zwei Threads warten auf sich gegenseitig. Solche Probleme hatte ich auch viel mit einem TeamSpeak Bot. Da hab ich Informationen über eine Thread List (oder wie die heißt) gemanaged, aber für einen Command brauchte ich eine Antwort, so hat der thread der grad die Liste abbarbeitet auf die Nachricht gewartet die darauf gewartet hat das die Liste freigegeben wird

[Timm Thaler]

Dein Problem klingt übrigens nach einem Deadlock. Also zwei Threads warten auf sich gegenseitig. Solche Probleme hatte ich auch viel mit einem TeamSpeak Bot. Da hab ich Informationen über eine Thread List (oder wie die heißt) gemanaged, aber für einen Command brauchte ich eine Antwort, so hat der thread der grad die Liste abbarbeitet auf die Nachricht gewartet die darauf gewartet hat das die Liste freigegeben wird

Das Programm an sich ist recht simpel, wenn auch noch bißchen Zusatzkram wie Logfile und Configfile dazukommt, so dass ich das hier nicht direkt einstellen kann. Ich vermute mal, es hängt bei einer Serverabfrage. Früher ist es - anscheinend - immer dann hängengeblieben, wenn der Router eine neue IP bekommen hat, aber da bin ich auch nicht sicher.

Werd mal die Logfunktionen etwas ausbauen und dann nochmal starten.

[Warf]

Das Programm an sich ist recht simpel, wenn auch noch bißchen Zusatzkram wie Logfile und Configfile dazukommt, so dass ich das hier nicht direkt einstellen kann. Ich vermute mal, es hängt bei einer Serverabfrage. Früher ist es - anscheinend - immer dann hängengeblieben, wenn der Router eine neue IP bekommen hat, aber da bin ich auch nicht sicher.

Werd mal die Logfunktionen etwas ausbauen und dann nochmal starten.

Ich würde die tatsächlich eher empfehlen den GDB zu verwenden Den Bot einfach mit dem GDB im hintergrund starten und warten bis er nix mehr macht, dann in die session Attachen und nachschauen:

Code: Alles auswählen

$ screen -mSL bot "gdb BotExec"
gdb> r
-- STRG + A & STRG + D
#warten
$ screen -r bot
^C -- Strg+C
gdb> backtrace
...

Das ist ein kleines beispiel mit Screen. Startet den Bot im GDB in einer screen session, mit r (run) startest du dann den GDB. Mit STRG +A gefolgt von STRG+D detachest du dann vom Screen. Der GDB führt den Bot dann ganz normal aus, und er sollte as usual funktionieren (eventuell etwas langsamer sollte aber verschmerzbar sein). Dann heißt es warten bis es nicht mehr geht, dann mit screen -r die Terminal Session wieder herstellen, mit Strg+C den Debugger auffordern das Programm zu unterbrechen (zeigt dir u.a. auch die aktuelle zeile an) und backtrace gibt dir ein Summary welche Funktionen auf dem weg hierher aufgerufen werden (also den Funktionsstack).

Ist deutlich einfacher als jede Zeile zu loggen (das wichtigste solltest du schon loggen, musst aber nicht so detailiert wie wenn du damit den fehler finden willst). Außerdem kannst du mit dem GDB in variablen reinschauen oder funktionen aufrufen, etc. um zu schauen warum es hängt

[mse]

Oder die Funktion 'Attach Process' der IDE verwenden. Dazu muss man die Processid des Programms herausfinden.

[Timm Thaler]

Muhaha, ich glaub ich hab die Stelle gefunden. Ich hab tatsächlich eine Abbruchbedingung gemacht für den Fall, dass der bot nicht auf die Abfrage antwortet. Dann soll er es noch zweimal versuchen und dann warten. Aber: Ich hab den Zähler für den Abbruch an die falsche Stelle gesetzt, so dass er alle 200msec tatsächlich immer wieder abfragt, woraufhin der bot anscheinend wegen DNS gar nicht mehr antwortet.

Dumm gelaufen.