Festellen ob Programm in der IDE/mit Debugger läuft?

[Bitschubser]

Hallo zusammen,

mir ist gerade aufgefallen, dass mir in FPC/Lazarus die von Delphi bekannte DebugHook System-Variable fehlt.

Suchen im Netz brachte mich nur zu der Erkenntnis, dass das Fehlen von DebugHook schon von Anderen bemerkt wurde - aber leider keine Lösung.

Daher die Frage: Wie kann ich im Programm feststellen, dass das Programm gerade in der IDE/mit Debugger läuft?

Plattform ist Linux, wenn es da nur was plattformabhängiges geben sollte.


Gruß, Ingo

[theo]

Kannst ja einfach schauen "wer" das Programm gestartet hat.
Unter Linux z.B. so:

Code: Alles auswählen

uses BaseUnix;
....
var SL:TStringList;
begin
  SL:=TStringList.Create;
  SL.LoadFromFile('/proc/'+inttostr(FpGetppid)+'/cmdline');
  ShowMessage(SL.Text);
  SL.Free;
end;   

[Bitschubser]

Kannst ja einfach schauen "wer" das Programm gestartet hat.

OK, das ist zumindest ein funktionierender Workaround, danke für die schnelle Antwort.

Da fällt mir mal wieder auf, dass ich von Linux eingentlich keine Ahnung hab...

Nachteil gegenüber "DebugHook" bleibt natürlich, dass deine Lösung nur funktioniert solange der Debugger gdb heisst, oder ich den Namen zumindest kenne.

[martin_frb]

Der /proc trick hat jede Menge Schwaechen.

1) /proc muss erreichbar sein
2) Der Debugger kann per attach an einen laufenden Prozess angebunden werden.

Unter Linux verwenden viele Debugger ptrace (man ptrace). Ob der debuggte Prozess das ueberpruefen kann weiss ich nicht. (ggf, vielleicht, indem man einen neuen Prozess started, der versucht den original Prozess zu debuggen?)

Die meisten Debugger setzen Breakpoints durch aendern des Codes. Das kann man durch eine Checksumme natuerlich erkennen.

Aber fuer alle Tricks einen Debugger zu erkennen, gibt es auch debug Methoden die Erkennung zu verhindern.

[marcov]

Nachteil gegenüber "DebugHook" bleibt natürlich, dass deine Lösung nur funktioniert solange der Debugger gdb heisst, oder ich den Namen zumindest kenne.

Nachteil von Debughook ist das es Delphi-only ist

[Bitschubser]

Aber fuer alle Tricks einen Debugger zu erkennen, gibt es auch debug Methoden die Erkennung zu verhindern.

Naja, mir ging es auch nicht darum zuverlässig zu erkennen ob irgendein Debugger dran hängt (um z.B. re-engineering zu verhindern) sondern um eine einfache Methode die bestimmte Routinen in meinem Programm automatisch zu deaktivieren die es nicht vertragen wenn an einem Breakpoint mal ein paar Sekunden angehalten wird...

Von daher, und weil /pro auf meinem aktuellen System funktioniert ist die Lösung OK - plattfromunabhängig wäre natürlich schöner...

[Bitschubser]

Nachteil von Debughook ist das es Delphi-only ist

Klar, aber ich denke man hätte das in Lazarus/FPC ohne Probleme übernehmen können - oder?
Da gibt es andere Sachen wo man sich lieber nicht nach Delphi hätte richten sollen...

[martin_frb]

Dann is proc ok.

Oder setze an den stellen keine breakpoints

Naja, das laesst sich natuerlich nicht vermeiden, aber wenn dein Programm sich im Debugger anders verhaelt als in real live, dann kann es passieren, dass das gesuchte Problem im Debugger nicht auftritt.

Man kann breakpoints setzen, die "nicht" anhalten. Das heisst Sie halten fuer ne halbe Sekunde (je nach Anzahl der entries in der Watchlist), dann laufen sie weiter, und die app behaelt den Fokus waehrend dieser Zeit.
Diese Breakpoints zeichnen einen Snapshot auf, den man hinterher in der Debug History ansehen kann.

In Breakpoint properties:
- check snapshop
- uncheck "break"
(autocontinue ist nicht noetig, wenn "break" nicht gesetzt ist)

[Bitschubser]

Dann is proc ok.
Oder setze an den stellen keine breakpoints

War vielleicht etwas zu allgemein formuliert:
Ich habe in dem aktuellen Projekt (bis zu) 8 unabhängige Threads laufen, einige davon haben ein spezielles Timeout-Handling was ggf. auch anspricht wenn der Thread zu lange an der falschen Stelle "steht" - das passiert dann auch wenn in einem anderen Thread ein Breakpoint erreicht wurde...
D.h. ich sehe im Breakpoint meine Eintrittsbedingungen und würde dann weiter steppen wollen - und dann kommt die Timeout-Behandlung von einem Thread dran auf dessen Kooperation ich angewiesen bin damit es weitergeht...

Naja, das laesst sich natuerlich nicht vermeiden, aber wenn dein Programm sich im Debugger anders verhaelt als in real live, dann kann es passieren, dass das gesuchte Problem im Debugger nicht auftritt.

Das ist klar, bin ich aber bei meinen Embedded/kommunikationslastigen Sachen eh gewöhnt.

Z.Zt. nutze ich den /proc-Ansatz mit Lazarus unter Linux auf einem embedded System um wie oben beschrieben beim Debugging die Timeout-Behandlung auszuhebeln, und den DebugHook unter Delphi 2010 auf Windows um beim Start in der IDE diverse Konsistenzprüfungen durchzuführen – z.B. sagt mir dann ein Meldungsfenster, dass irgendjemand vergessen hat die Beschriftung für einen Button auf Japanisch zu übersetzen.
Ein Benutzer soll natürlich weder das Meldungsfenster sehen noch beim Programmstart die Konsistenzprüfung abwarten müssen – er könnte ja auch wenn wir ihm tatsächlich was Inkonsistentes geliefert hätten eh nix dagegen machen.

Man kann breakpoints setzen, die "nicht" anhalten. Das heisst Sie halten fuer ne halbe Sekunde (je nach Anzahl der entries in der Watchlist), dann laufen sie weiter, und die app behaelt den Fokus waehrend dieser Zeit.
Diese Breakpoints zeichnen einen Snapshot auf, den man hinterher in der Debug History ansehen kann.

In Breakpoint properties:
- check snapshop
- uncheck "break"
(autocontinue ist nicht noetig, wenn "break" nicht gesetzt ist)

Das kannte ich schon.
[advocatus diaboli]
Wenn allerdings der snapshot allerdings auch nur näherungsweise solange dauert wie das updaten einiger etwas komplexerer Watch-Ausdrücke würde ich auch da schon in einen Timeout reinlaufen (selbst bei T >> 1sec.) [/advocatus diaboli]