ich kriege manchmal beim Programmieren einfach mal nen Segfault...Ist ja klar, wenn man nen Fehler einbaut ...Aber:
Jedesmal muss ich ewig mim Debugger rummachen, bis ich die Stelle gefunden habe wo der "rausfliegt". Gibts da nichts was eim gleich Zeile oder so sagt wos geknallt hat ??
den Segfault eben, wollte ich mit ein paar cout Meldungen eingrenzen...und ich hab ihn auch immer Weiter eingeschränkt, bis er plötzlich nicht mehr kam ! Auch nachdem ich die couts wieder entfernt habe....der Segfault is weg
^^Wie kann sowas passieren... und immernoch: ich brauche für die "permanenten" Segfaults ein tool, was mir sofort angeben kann, an welcher Stelle es passierte..
entweder man macht es so, wie es Descartes beschrieben hat, oder man grenzt die Stelle ein, wo es passiert (z.B. mit einer Logdatei) und stiert dann auf den Quellcode. Mit ausreichend Erfahrung (wie ich sie zu haben meine) kommt man oft ohne Debugger aus <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
Wenn der Segfault plötzlich verschwindet, ist der Fehler mit Sicherheit nicht behoben. Dann hast du eine Speicherkorruption, verursacht durch fehlerhaften Umgang mit malloc/free/new/delete oder Schreiben über das Ende eines Arrays.
Gruß,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
Hast du das Programm auch ohne Optimierungen also z.b. mit "-O -g" compiliert?
Solche zufällig verstreuten Fehler die wie von Geisterhand auftauchen und wieder verschwinden haben meistends damit zu tun. Ein Debugger hilft dann auch nicht weiter weil durch die Optimierungen die Adressen nicht mehr zum Debugcode stimmen. Manchmal kann im übrigen auch ein coredump gut geeignet sein um einen Fehler nachträglich zu finden.
ich benutze immer den "ddd" (Frontend zu gdb), ist das mit dem Befehl vom Descartes genauso schnell/langsam zu finden ? Wenn man nämlich C++ Code debugged, dann landet der immer wieder in so C++ functionen/wasauchimmer, was ich nicht verstehe, wo er aber manchmal ewig bleibt (wenn ich immer auf "Step" klicke). Schoen wäre es, wenn man ein Programm hätte, was, wenn man es über ein segfault binary laufen lässt gibt:
Segfault in:
void c++_spezial_allocation_template() in Z.563;
int facultaet(int) Z.45 in:
void calculation in Z.213 :
class math in Z.10
int main() in Z.18
Da könnte ich dann genaustens und ohne Verzögerungen an den Fehler gehen
Ich möcht ja nix sagen, aber ich hab neulich ein ddd-Tutorial gemacht, und der ddd machts doch schon so...? Wenn ich ein Programm aufrufe (mit ddd), und es tritt ein seg. fault auf, dann springt mir der ddd zu der zeile, wo der fehler auftrat...
klar springt der ddd zur Zeile Nur ist die meistens (sprich immer) in einem andern Code, der nicht von mir stammt (in irgendwelchen C++ STL Dateien ist der da meist drin).
Du musst einen backtrace machen. Dann siehst du, wo in deinem Code der Fehler beginnt. Unter GDB gibst du dazu einfach "bt" ein, bei DDD gibts glaub ich ein Fenster und du kannst dann klicki klicki machen.
Coredump halt ich für besser geeignet.
Einfach mit ulimit -c die maximale Grösse der core-Datei festlegen und nach dem segfault in den gdb laden.
(ulimit -c unlimited setzt die grösse des Corefiles auf das verfügbare Maximimum)
Nach 'gdb programmdatei core' kann man dann immer noch ein Backtrace machen (bt) sich Variablen anschauen (p) usw.
Halte ich für effizienter und angenehmer als mit dem DDD "rumzumachen".
...Aber:
