Debugging unter Linux/Unix ist ein großer Haufen Mist. Zumindest, wenn man schon mal mit Visual Studio gearbeitet hat. Ich sitze gerade an einem Produkt, dass massiv Prozesse forkt und irgendwo in einem Child steckt ein Bug.
Weil das Erzeugen und das Beenden der Prozesse ziemlich schnell geht, kann man sich nicht an den Prozess attachen, er ist schon lange wieder weg, bevor der Debugger oben ist. Findige Kollegen haben dann soetwas in den Code eingebaut:
if (getenv("DEBUG_XYZ")) kill (getpid(),SIGSTOP); |
if (getenv("DEBUG_XYZ")) kill (getpid(),SIGSTOP);
Ich muss also eine Umgebungsvariable DEBUG_XYZ
setzen, den Master-Prozess neu starten und irgendwann wird der fragliche Prozess als Gestoppt in der Prozessliste stehen, ich kann mich in Ruhe attachen und debuggen.
Die Lösung hat natürlich massive Nachteile: ich muss den Code jedesmal ändern, wenn ich den „Breakpoint“ verschieben will und schlimmstenfalls kommt solcher Code versehentlich ins finale Release.
Es geht ein bisschen besser, wenn man gdb benutzt, der kann nämlich beim Fork entweder dem Parent- oder dem Childprozess folgen:
set follow-fork-mode mode
Wobei mode entweder „child“, „parent“ oder „ask“ ist. Nun will niemand „nativ“ mit dem gdb debuggen, man spannt Netbeans davor. Damit man aber in Netbeans den follow-fork-mode setzen kann, braucht man erstmal eine GDB Debugger Console:
-J-Dgdb.console.window=true
muss unter netbeans_default_options
in der netbeans.conf
hinzugefügt werden.
Jetzt kann man zumindest das Debugging starten und sich entscheiden, ob man den Childs oder den Parents folgt. „ask“ geht komischerweise nicht. Auch muss man scheinbar den follow-fork-mode bei jedem Start neu setzen.
Das ist immernoch ein riesengroßer Haufen Mist. Aber zumindest habe ich schöne gelbe Gummistifel an. Geht das nicht einfacher? 🙁