Pfeifen bearbeiten? - bin mit meinem Latein am Ende :(

Hallo,

ich bräuchte mal wieder Nachhilfe in C++

Es geht um die CommandReader Klasse. Ich hatte die als Schnittstelle gedacht, um Ausgaben eines beliebigen Hilfsprogrammes verarbeiten zu können.

Wenn das Hilfsprogramm viel Output produziert, sieht es erstmal nicht schlecht aus.
Erst so nach und nach bin ich drauf gekommen, dass es wohl mit dem Ende der Ausgabe zu tun hat.
Dann bekomme ich beim Debuggen mit code::blocks SigSegV-Abstürze.

In dieser Testdatei kann das Problem mit einem Brechpunkt in Zeile 87 nachgestellt werden.
Dazu am besten im Verzeichnis, in dem die Debug-Sitzung abgehalten wird, eine Datei "testMedia.files" erstellen, mit dem Pfad einer JPeg-Datei in der ersten Zeile.

Dann kann man (mit dem Brechpunkt in Zeile 87) den Debugger starten.
Wenn der Debugger anhält, "Continue" ausführen, sodass er ein zweites Mal an dem Brechpunkt anhält.
Wenn man jetzt reinsteppt, gibt es gleich vor der ersten Codezeile der Funktion den Absturz.

valgrind bekommt von dem Absturz leider nix mit, was mich vermuten lässt, dass es mit der Inter-Prozess-Kommunikation zu tun hat.
Ich hatte auch schon trace-children probiert, leider ohne Erfolg, bzw. ohne hilfreiche Ausgabe.

Meine Vermutung geht in die Richtung, dass wenn das Hilfsprogramm, welches über exec gestartet wurde, sich beendet, die Daten in der Pipe nicht mehr gelesen werden können.
Da gibt es doch bestimmt Trix, wie man(n) das Problem umschiffen kann.

Bin für jeden Tip dankbar.

Gruß Gero

Hallo,

danke für Deine Unterstützung!

Zitat

Was sagt denn der Backtrace vom GDB?

Wer hat Deine Cola getrunken ... ?

... äh, sorry - bin Mausschubser. Also was mit IDE geht, kann ich Dir liefern. Meer weiß ich net.
Ich hänge mal den debug-log von code::blocks an. Vielleicht bringt das ja schon was?

Zitat

GGf. auch einfach mal die Zeile ie = mir->ReadEntry() in die Schleife verschieben und nur auf ie prüfen. Dann kannst du sehen, ob du eventuell in ReadEntry() suchen musst.

Na, das betrachte ich als sicher - dass es in ReadEntry() passiert.

...oder ... Hm, wie soll ich das sagen ...
es passiert ja in einem anderen Prozess, bzw. der Tod des Kind-Prozesses hat Auswirkung auf die Pipe - die ja beide Prozesse verbindet.
In ReadEntry() soll der nächste Lesezugriff erfolgen.
Wobei ...
... eigentlich ist der Pipe-Inhalt ja schon in einen Puffer im Heap gelesen und ReadEntry liest nur aus diesem Puffer.

Bei "ie" erwarte ich keinen Ärger. Das gleiche Konstrukt funktioniert ja im ConfigReader. Der läuft in einem Prozess ab, sodass valgrind was merken würde ...
Als ich gerade den debug-log produziert habe, habe ich mir alle Variablen, u.a. auch mir ausgeben lassen.
Dabei fiel mir auf, dass der erste Durchlauf in Ordnung ist.
Wenn der Debugger das 2. Mal auf dem Breakpoint steht, sieht die Welt auch noch in Ordnung aus.
Wenn ich dann "step into" ausführe, ist der this-Zeiger NULL

Jetzt weiß ich noch weniger, als zuvor

Danke Euch beiden!

Zitat

Na wunderbar, dann ist DDD dein Freund.

Puh - da fühlt man sich an AIX-Terminals vor 20 Jahren zurückversetzt
Damals waren solche Oberflächen richtig hipp

Ich habe mal eine debug-Session probiert - Zäh, richtig zäh - und ich habe auch nicht mehr Info, als bei code::blocks bekommen.

Zitat

Schreibst du mit Eclipse?

Ne, ich habe es nicht geschafft, dass der Parser, der den Code mit Fehler-Wellen "vollsaut" die gleichen Einstellungen verwendet, wie die, mit denen das Projekt beim Build fehlerfrei und ohne Warnung übersetzt. Bei mir ist immer die halbe Seite rot - so kannich net arbeiten.

Derzeit nehme ich Netbeans zum editieren und code::blocks zum Debuggen. Netbeans hat zwar auch Probleme, friend-Deklarationen aufzulösen, aber es sind wesentlich weniger falsche Fehler, als mit Eclipse.

Ich komme zwar schon mit der Befehlszeile von Linux klar, verwende sie aber nur dort, wo ich muss.
Wenn Du mir also sagst, wie ich den post-mortem-dingens per Befehlszeile starte, mache ich das.

Das Testproggy ist mit Debug-Option übersetzt, aber das ulimit und starten hat keine core-Datei erzeugt.
Es ist ja auch so, dass die Hauptanwendung ohne Absturz durchläuft. Nur in den jeweiligen Kindprozessen knallt es.
Das zeigt sich daran, dass nur ein Teil der erwarteten Ausgaben kommt.
Mein Problem ist, dass ich nicht das geringste Gespür für das Phänomen habe und nicht weiß, in welche Richtung ich suchen sollte.

Das SigSegV habe ich bislang nur in der IDE beim debuggen gesehen.

Gruß Gero

Moin moin,

Zitat

Na ja, du hast dich doch als Mausschubser bezeichnet. Ich benutze gdb nur von der Konsole aus.

Jou - so hartchor bin ich net. Methodus hat schon recht: "eigentlich" bin ich Eclipse Anwender.
... und gerade beim debuggen pflastere ich den Bildschirm gerne mit allerlei Infofenster voll ...

Zitat

Das ist leicht behebbar: du musst lediglich das Projekt richtig anlegen: erstell ein neues Projekt --> Makefile projekt with existing makefile.

Ok, ich werde nomml einen Versuch unternehmen.

Zitat

Was steht da, wenn das Programm abstürzt?

Ich versuche es nomml nach zu stellen.
Mir ist noch ne andere Idee zum testen gekommen. Melde mir später wieder.

Gruß Gero

//Edith
So, habe gerade meine Projekte in Eclipse nach Deinem Rad importiert. Jetzt ist für mich Eclipse für C/C++ endgültig gestorben!
Markiert das plöde Teil doch fprintf als fehlerhaft, weil unbekannt, während im Kopf der Datei stdio.h eingebunden wird. Was bitte schön kann Eclipse importieren?
... ist doch - grmpf ... also wirlich!

//Edith, die andere
Hier mal der "Absturz" (zumindest die Meldung von code::blocks aus dem debug.log)

At /d/linux/CMP/libs/mediaScan/src/MediainfoReader.cc:46
At /d/linux/CMP/libs/mediaScan/src/MediainfoReader.cc:47
Program received signal SIGSEGV, Segmentation fault.
In std::string::size() const () (/usr/lib/libstdc++.so.6)
Program received signal SIGSEGV, Segmentation fault.

während ich mit ddd ganz "normal" reindebuggen kann und das SIGSEGV nicht bekomme. Vielleicht ist das Signal ja eine Nickligkeit von code::blocks?

Jedenfalls scheint der Dip mit dem Tripple-D wertvoller zu sein, als ich ihn eingeschätzt habe. Deshalb nomml ein extra Dankeschön.
Werde mich mal mit dem Steinzeit-Teil auseinander setzen (dabei erreicht das Teil im Alter nichtmal meine Dienstjahre )

//Edith, die Tritte
Whow - neuer Tag, neues Glück
Wenn die Rübe frei ist, klappet es einfach.
Mit Tripple-D habe ich meinen Fehler gefunden und ausgemerzt - jetzt funzt es wie erwartet
Gerald - Du bist mein Held des Tages. Ich muss Dir einfach mal knuddeln