Ich habe ein C-Programm, welches im Verlauf seiner Abarbeitung immer
wieder einfache Debugmeldungen via printf() ausgibt.
Wird die nachfolgende Stelle im Programmcode erreicht, werden zwar noch
die hierin enthaltenen Ausgaben ueber die Standardausgabe vorgenommen,
dann aber war es das.
Setze ich nach diesem Codeabschnitt eine printf() Funktion, gibt diese
nichts mehr zurueck.
Das Programm läuft ohne Warnungen und Fehlermeldungen durch den
Compiler.
Matthias schrieb:> Ich habe es mit verschiedenen URLs ausprobiert und jedesmal kommt eine> saubere Liste mit den entsprechenden IPs.>> Ja, würde ich sagen.
Wie stellst du fest, dass sich die Schleife nicht bei inet_ntoa
aufhängt?
Danke für die Rückmeldungen.
@Dirk
Was ich nicht verstehe ist die Frage nach dem Warum. Wieso sollte ich
das flushen?
Die zweite Frage, welche ich mir stelle, wieso erhalte ich, wenn es denn
nötig wäre, keinerlei Rueckmeldungen seitens des Compilers?
Mein derzeitiges Programm ist noch relativ ueberschaubar. Was mache ich,
wenn ich tausende Code-Zeilen habe und der gleiche Fehler auftritt? -und
der Compiler alles so durchwinkt?
Matthias schrieb:> Danke für die Rückmeldungen.>> @Dirk> Was ich nicht verstehe ist die Frage nach dem Warum. Wieso sollte ich> das flushen?
Brauchst du nicht. Bei Dirk fehlen die Zeilenumbrüche, da braucht man
ein explizite Flush, um die Daten rauzuschicken.
> Die zweite Frage, welche ich mir stelle, wieso erhalte ich, wenn es denn> nötig wäre, keinerlei Rueckmeldungen seitens des Compilers?
Rückmeldung zu was?
> Mein derzeitiges Programm ist noch relativ ueberschaubar. Was mache ich,> wenn ich tausende Code-Zeilen habe und der gleiche Fehler auftritt?
Du teilst dein Programm in überschaubare eineln testbare Module auf.
Wenn das nur ein großer Klumpen ist, bei dem alles kreuz und quer läuft,
wird's natürlich schwierig.
@Rolf Magnus
> Rückmeldung zu was?
Genau das frage ich mich ja. Ich weiß nicht, wo im obigen Code ein
Fehler sein soll.
Ich bin schon dabei zu modularisieren und meinen Code in Bibliotheken
auszulagern.
Mir ging es um die Frage, wieso die Standardausgabe ploetzlich nichts
mehr rueckmeldet. Aufgrund von Dirks Antwort bin ich von einem Fehler im
Code ausgegangen, den ich aber nicht finden kann.
Davon mal abgesehen, wenn das Phaenomen auftritt, das STDOUT nicht mehr
laeuft, wieso meldet sich dann der Compiler nicht?
Bis zum obigen Codestueck lauft alles reibungslos, danach herrscht
Stille. Mir ist nicht klar, wieso sich der Schleifenteil aufhaengen
koennte.
Matthias schrieb:> Die zweite Frage, welche ich mir stelle, wieso erhalte ich, wenn es denn> nötig wäre, keinerlei Rueckmeldungen seitens des Compilers?
Der Compiler ist kein Debugger.
Matthias schrieb:> Bis zum obigen Codestueck lauft alles reibungslos, danach herrscht> Stille. Mir ist nicht klar, wieso sich der Schleifenteil aufhaengen> koennte.
Ich habe die Ausgabe in drei Teile aufgeteilt. Wenn du in der Letzten
Ausgabe kein (ok) in der Zeile steht, hängt das Programm bei inet_ntoa
Das flush wird benötigt, damit die bisher geschriebenen Zeichen auch
(vor dem Absturz) ausgegeben werden.
Das ist nur Testcode.
Rolf Magnus schrieb:> Brauchst du nicht. Bei Dirk fehlen die Zeilenumbrüche, da braucht man> ein explizite Flush, um die Daten rauzuschicken.
Da hat der Rolf recht. Kurz recherchiert, aber es war so, dass stdout
"line buffered" ist. Daneben gibt es noch unbuffered (z.B. stderr) und
full buffered.
siggi schrieb:> Matthias schrieb:>> Die zweite Frage, welche ich mir stelle, wieso erhalte ich, wenn es denn>> nötig wäre, keinerlei Rueckmeldungen seitens des Compilers?>> Der Compiler ist kein Debugger.
Der Compiler hat nichts mit der Codeausführung zu tun. Verwende entweder
einen Debugger, dann siehst Du ja wo Du hängenbleibst oder wenn man
Systemcalls beobachten möchte, dann kannst Du ja strace unter Linux
aufprobieren. printf() solltest Du schön verfolgen können.
Manche Warnungen muss man auch explizit aktivieren bzw. wenn man selber
Code schreibt, dann sollte man auch Warnungen als Fehler behandeln
lassen.
Machst Du an anderen Stellen im Code noch etwas mit Deskriptoren.
Schließt den falschen oder änderst Eigenschaften?
mar IO schrieb:> oder wenn man> Systemcalls beobachten möchte, dann kannst Du ja strace unter Linux> aufprobieren. printf() solltest Du schön verfolgen können.
Dann muß man im Output aber nicht nach printf(), sondern nach write()
schauen.
Rolf Magnus schrieb:> mar IO schrieb:>> oder wenn man>> Systemcalls beobachten möchte, dann kannst Du ja strace unter Linux>> aufprobieren. printf() solltest Du schön verfolgen können.>> Dann muß man im Output aber nicht nach printf(), sondern nach write()> schauen.
Oder nach dem, was man ausgeben möchte.
'strace' war mir neu, daher habe ich erst mal danach geixquicked und
habe das gefunden.
> As strace only details system calls, it cannot be used to detect as many
problems as a code debugger such as GNU Debugger (gdb).
Da mir gdb nicht ganz so fremd wie strace ist, habe ich mein Programm
einmal damit untersucht und den Fehler widerum an einer ganz anderen
Stelle lokalisiert und behoben.
Da sich das Ereignis erst zur Laufzeit ergeben hat ist jetzt auch klar,
wieso der Compiler sich nicht gemeldet hat. Haette man, oder ich in
diesem Fall, auch eher drauf kommen koennen!
Kurioserweise haben die Ausgaben ueber die Standardausgabe nach dem
eingangs erwaehnten Codesegment ihren Dienst quittiert, wobei der
eigentliche Fehler laut 'gdb' aber erst 30 Codezeilen spaeter verursacht
worden ist.
Ich habe einmal in einem C-Buch gelesen, dass es die 'einfachste' Art
des "Debugging" ist, sein Programm mit printf()-Funktionen und hierin
enthaltenen Rueckgaben zu versehen.
Deshalb bin ich immer bei dem obigen Code gelandet. Ich denke, ich werde
mich jetzt oefter auf 'gdb' verlassen, sollte erneut ein Laufzeitproblem
auftreten.