Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Ich habe es gestern schon zum zweiten Mal innerhalb weniger Monate geschafft, den Debugger abstürzen zu lassen. Ich verwende gdb mit ddd. Das Fehlerfenster von ddd zeigt folgenden Text:
GDB terminated abnormally (Segmentation fault)
[Restart GDB] [Exit] [Help]
Das merkwürdige ist, das erst alles normal läuft, aber während ich nach unten scrolle, um einen weiteren Breakpoint zu setzen, kommt dann plötzlich das Fehlerfenster. Wenn ich dann auf "Restart GDB" drücke, sieht es so aus, als könne ich normal weiter arbeiten. Aber wenn ich dann ddd/gdb schließe, läuft meine Anwendung weiter. Diese Verhalten ist nicht gezielt reproduzierbar, aber da es schon zum zweiten Mal passiert ist, macht mich das nachdenklich. p.s. Screenshot kann ich nachliefern.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17546
Wohnort: Berlin
|
Ein Bug im Debugger selbst.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Ok, ist naheliegend. Aber mit "manchmal" und "nicht gezielt reproduzierbar" kann ich auch keinen Bug Report absetzen. Ich frage mich daher, womit ich provoziert habe, das der mögliche Bug sich bemerkbar macht.
Das ist bisher nur bei meinem größten Projekt passiert (mehrere Tabs in Geany aktiv). Firefox ist mit etlichen Tabs aktiv. Zwei davon brauche ich für die Online-Doku des GUI-Toolkits. Parallel ist auch noch Gedit geöffnet, da ich einige Quelltexte nebeneinander sehen muss.
Das klingt alles nach hohem Speicherbedarf, aber ich habe keinen Hinweise, das mein System swapped. Was mir jetzt aber einfällt: Ich setze manchmal neue Breakpoints, während das Programm läuft, also nicht auf einem Breakpoint wartet. Der Debugger sendet dann SIGINT an die Anwendung. Möglicherweise ist das in einer GUI Anwendung problematisch.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12795
|
Dakuan schrieb: Ok, ist naheliegend. Aber mit "manchmal" und "nicht gezielt reproduzierbar" kann ich auch keinen Bug Report absetzen.
Du könntest das ulimit so setzen, dass der Debugger einen Core produziert. Das wäre das erste, was ich machen würde. Wenn es dann wieder auftaucht, haben die Entwickler wenigstens einen Anhaltspunkt.
Ich frage mich daher, womit ich provoziert habe, das der mögliche Bug sich bemerkbar macht.
Das ist bisher nur bei meinem größten Projekt passiert (mehrere Tabs in Geany aktiv). Firefox ist mit etlichen Tabs aktiv. Zwei davon brauche ich für die Online-Doku des GUI-Toolkits. Parallel ist auch noch Gedit geöffnet, da ich einige Quelltexte nebeneinander sehen muss.
Ich glaube, das ist alles ziemliche Raterei.
Das klingt alles nach hohem Speicherbedarf, aber ich habe keinen Hinweise, das mein System swapped.
Das kann man ja leicht mit free oder atop überprüfen.
Was mir jetzt aber einfällt: Ich setze manchmal neue Breakpoints, während das Programm läuft, also nicht auf einem Breakpoint wartet. Der Debugger sendet dann SIGINT an die Anwendung. Möglicherweise ist das in einer GUI Anwendung problematisch.
Wenn sie das Signal nicht korrekt verarbeitet. Aber bei Dir stürzt ja der Debugger ab, nicht die Anwendung. Wie sollte denn das Programm den Debugger zum Absturz bringen?
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Du könntest das ulimit so setzen, dass der Debugger einen Core produziert.
Ups, da hast Du mich schon wieder auf dem linken Fuß erwischt. "ulimit" kannte ich bisher noch nicht. Ich glaube mich zu erinnern, das ich auch in diesem Fall einen Coredump hatte. Allerdings lösche ich diese meistens sofort, da ich noch nicht herausgefunden hatte, was man damit anfangen kann. Meistens (95%) habe ich diese ja auch selber durch nicht ausgereifte Zeigerprogrammierung verursacht.
Das kann man ja leicht mit free oder atop überprüfen.
Das werde ich mal im Auge behalten. Bisher habe ich mich auf htop verlassen.
Aber bei Dir stürzt ja der Debugger ab, nicht die Anwendung. Wie sollte denn das Programm den Debugger zum Absturz bringen?
Ich bin mir da inzwischen nicht sicher, ob ich das richtig unterscheiden kann. Es könnte ja auch ein Kommunikationsproblem zwischen ddd und gdb sein. Da ich mit dem Z80 groß geworden bin, und schon da eigentlich nicht erklärbare Fehlerbilder gesehen habe, halte ich fast alles für möglich. In diesem letzten Fall bin ich mir allerdings sicher, dass mein Anwenderprogramm aus Sicht des Systems keinerlei Probleme verursacht hat. Lediglich die Datenauswertung war fehlerhaft, was mich fast 2 (peinliche) Tage gekostet hat. Da ist es dann schon nervig, wenn man nach jeder vermeintlichen Programmkorrektur einige Minuten benötigt, den Debugger zur problemverdächtigten Funktion zu führen und wo er dann nicht mehr mitspielt.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12795
|
Dakuan schrieb: Du könntest das ulimit so setzen, dass der Debugger einen Core produziert.
Ups, da hast Du mich schon wieder auf dem linken Fuß erwischt. "ulimit" kannte ich bisher noch nicht.
Oh. Gut, dass ich das mal erwähnt habe. 😬
Ich glaube mich zu erinnern, das ich auch in diesem Fall einen Coredump hatte. Allerdings lösche ich diese meistens sofort, da ich noch nicht herausgefunden hatte, was man damit anfangen kann. Meistens (95%) habe ich diese ja auch selber durch nicht ausgereifte Zeigerprogrammierung verursacht.
Ja, in dem Fall wäre aber ein Core des Debuggers vermutlich hilfreich in der Fehlersuche bzw. beim Erstellen des Bugreports.
Das kann man ja leicht mit free oder atop überprüfen.
Das werde ich mal im Auge behalten. Bisher habe ich mich auf htop verlassen.
Geht vermutlich auch. Ich hatte die irgendwann mal verglichen und fand atop besser. Frag mich jetzt aber nicht, warum. ☺
Aber bei Dir stürzt ja der Debugger ab, nicht die Anwendung. Wie sollte denn das Programm den Debugger zum Absturz bringen?
Ich bin mir da inzwischen nicht sicher, ob ich das richtig unterscheiden kann. Es könnte ja auch ein Kommunikationsproblem zwischen ddd und gdb sein.
Das könnte aber nur indirekt zu einem Core führen, indem z.B. durch irgendeine Nachricht gdb dazu gebracht wird, auf nicht initialisierten Speicher zuzugreifen.
Da ich mit dem Z80 groß geworden bin, und schon da eigentlich nicht erklärbare Fehlerbilder gesehen habe, halte ich fast alles für möglich.
Die Architekturen sind allerdings sehr verschieden. Vor allem gibt es beim Z80 keine MMU, die für ein Unix zwingend nötig ist - und auch bestimmte Fehlerbilder komplett ausschließt (versehentliches Schreiben auf den Speicher eines anderen Prozesses z.B.).
In diesem letzten Fall bin ich mir allerdings sicher, dass mein Anwenderprogramm aus Sicht des Systems keinerlei Probleme verursacht hat. Lediglich die Datenauswertung war fehlerhaft, was mich fast 2 (peinliche) Tage gekostet hat. Da ist es dann schon nervig, wenn man nach jeder vermeintlichen Programmkorrektur einige Minuten benötigt, den Debugger zur problemverdächtigten Funktion zu führen und wo er dann nicht mehr mitspielt.
Übersetzt Du Dein Programm mit Optimierungen? Ggf. kann der gdb mit irgendetwas in Deinem Programmcode nicht richtig umgehen. Probier doch mal, Optimierungen ab- oder anzuschalten. Ich vermute mal, Debugger und Compiler sollten ungefähr auf dem selben Stand sein (z.B. beides aus den Paketquellen oder beides selbst übersetzt, aber kein Mischmasch).
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Übersetzt Du Dein Programm mit Optimierungen?
Nein, zumindest nicht während der Entwicklung.
Debugger und Compiler sollten ungefähr auf dem selben Stand sein...
Sind beide aus den Paketquellen. Nur FLTK ist direkt von deren Website. Wenn die nächste längere Debugging Sitzung ansteht, werde ich mal sehen ob mein System sich ein
ulimit -c unlimited
einfach so gefallen lässt.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12795
|
Dakuan schrieb:
Wenn die nächste längere Debugging Sitzung ansteht, werde ich mal sehen ob mein System sich ein
ulimit -c unlimited
einfach so gefallen lässt.
Wieso sollte es nicht?
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Weil ich an mehreren Stellen, z.B. hier, gelesen habe, das zuvor evtl. noch einige Configs geändert werden müssen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12795
|
Dakuan schrieb: Weil ich an mehreren Stellen, z.B. hier, gelesen habe, das zuvor evtl. noch einige Configs geändert werden müssen.
Bei meinem 14.04 gibt es keine Fehlermeldung der Art und beim Nachschauen ist es auch tatsächlich "unlimited". Die verlinkte Seite ist m.E. mit Vorsicht zu genießen: Punkt 1 unter "Solution" ist völlig irrelevant für die Fehlermeldung. Und selbst, wenn man solch einen Eintrag in einer der RC-Dateien hat, kann man immer noch das Limit der aktuellen Shell entsprechend höher setzten. Alle Prozesse, die direkt von dort und nicht etwa über eine weitere interaktive Shell gestartet werden, erben das neue Limit. Auch Formulierungen "Perhaps the last step number 3 is not necessary, but we have figured out, that this is the way which always work." sind nicht dazu angetan mir zu vermitteln, dass die Autoren verstanden haben, wie das funktioniert. Ich würde eher mal bei http://www.tldp.org/ schauen. Wenn man da nach "core limit" sucht findet man z.B. diese Seite als ersten Treffer. Die ist kürzer und erklärt m.E. besser, was Sache ist.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Tatsächlich, lässt sich einfach so an und abschalten. Da mir 'ulimit' bisher unbekannt war, dachte ich es ist besser mich mal schlau zu machen, bevor ich wieder Blödsinn schreibe. Damit bin ich dann wohl ein Opfer der Bewertungsmethode der Suchmaschine geworden, die sich nicht nach sachlicher Kompetenz richtet. Ich werde nachher noch ein wenig rumtesten. Aber wenn man vorbereitet ist, passiert ja meistens nichts.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Es ist jetzt wieder passiert. Ich bin mir aber nicht sicher wer da spinnt. Das Anwenderprogramm "stand" auf einem Breakpoint. Ich habe dann im DDD hochgescrollt, um anderswo eine Variable zu untersuchen (owner). Nach einiger Zeit des Nachdenkens habe ich wieder heruntergescrollt und dabei ist es dann passiert. Ausgegeben wurde dann folgender Text:
(gdb) ptype owner
type = struct Fl_Window {
<incomplete type>
} *
(gdb)
Segmentation fault
Restarting GDB
(gdb) file zk3
(gdb) core-file /home/dakuan/prog/db/zk3/core
warning: core file may not match specified executable file.
Core was generated by `gdb -q -fullname zk3'.
Program terminated with signal 11, Segmentation fault.
[New process 6832]
#0 0x080fa7ea in ?? ()
(gdb)
Im Backtrace waren nur Hex Adressen zu sehen, was mich vermuten lässt, das meine Anwendung daran nicht beteiligt war. Ich werde die Entwicklung auf einem neueren Rechner fortsetzen um zu sehen, ob der Fehler dort auch auftritt. Aber an die "normalen" Core Dumps habe ich mich gewöhnt. Es vereinfacht die Arbeit, wenn man im Fehlerfall auch nachträglich den Fehlerort angezeigt bekommt. Nachtrag: Auch in diesem Fall lief das Anwenderprogramm problemlos weiter, auch nach Beendigung des DDD.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12795
|
Es sieht mir fast so aus, als ob der Fehler in der Zusammenarbeit von gdb und ddd besteht - insbesondere, wegen "type = struct Fl_Window { <incomplete type> } *" und weil der Fehler ja beim Scrollen auftrat. Vielleicht ist es ein Bug in gdb - oder aber in ddd .
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6338
Wohnort: Hamburg
|
Es sieht mir fast so aus, als ob der Fehler in der Zusammenarbeit von gdb und ddd besteht
Deswegen war ich mir auch nicht mehr sicher, wer da spinnt.
insbesondere, wegen "type = struct Fl_Window { <incomplete type> } *"
Da bin ich mir nicht sicher, ob das damit zusammenhängt. Die Struktur ist ziemlich kompliziert und ist von Fl_Group abgeleitet (wahrscheinlich weil man in einem Fenster typischerweise mehrere andere Objekte gruppiert) und enthält diverse "#if..." Statements. Also ich blicke da auch nicht komplett durch. Aber vielleicht ist das jetzt mal ein Grund, den inneren Schweinehund zu überwinden und einmal nemiver auszuprobieren.
|