# cmake und gdb



## Der Wolf (23. Februar 2009)

Hallo Leute,

vielleicht gibt es ja einen ähnlichen Thread schon hier im Forum, aber bisher habe ich nirgends was passendes gefunden und mir geht nach fast 9 Stunden die Puste aus. Deswegen versuche ich es nun doch auf diesem Weg, auch wenn ich mich damit vielleicht in die Nesseln setze. ;-)

Also, bei der Entwicklung meines Programms ist es leider zu Fehlern gekommen, die, ganz toller Weise, immer an unterschiedlichen Stellen im Code auftreten ... sind allerdings nur 3-4 verschiedene Stellen bisher, glaube ich. ;-)

Ich wollte daher mein Programm mit dem GDB debuggen was auch so ganz gut klappt. Leider zeigt er mir bei meinen Funktionen nur an, welche Funktion gerade abgearbeitet wird, aber nicht in welcher Zeile es zu dem Segmentation fault kommt. Die Zeilenangabe bekomme ich nur bei den Bibliotheken die ich habe einbinden lassen. Das sieht für mich so aus, als würde der Code nicht mit der -g Option kompiliert werden. Aber ich habe sie eigentlich per ccmake mit angegeben. Vllt sieht einer von euch den Fehler. Ich sehe den Wald langsam vor lauter Bäumen nicht mehr. Ich habe ein Bild angehängt, wo alle Optionen angezeigt sind, die ich per ccmake . angegeben habe.

Schonmal Danke im Voraus.

Gruß
Ein müder Wolf.


----------



## Der Wolf (24. Februar 2009)

Hat denn niemand eine Idee? Oder will mir keiner helfen?


----------



## deepthroat (24. Februar 2009)

Hi.

Warum schaust du nicht ins Build-Log (CMakeFiles/CMakeOutput.log) mit welchen Optionen der Compiler wirklich aufgerufen wurde? 

Gruß


----------



## Der Wolf (25. Februar 2009)

Hmm ... ehrlich gesagt habe ich das nicht gemacht, weil ich mich mit cmake nicht soooo gut auskenne und nicht wusste das der diese log Datei anlegt. Danke schonmal
für den Tipp. 

Ich habe jetzt einfach auch mal folgendes versucht:


```
cmake .
  make VERBOSE=1
```

Dadurch konnte ich im Terminal verfolgen was genau der compiler macht und ausgegeben hat er folgendes:

 /usr/bin/c++ -o -g -gdwarf-2 ....

also sollte der Code mit debug makros versehen sein. Dann liegt der Fehler woanders. Oder sehe ich das falsch, dass der gdb mir normalerweise in meinem Code auch die Zeile angeben sollte wo es zum Crash gekommen ist und nicht nur die Funktion in der es passiert ist?

Gruß
Der Wolf


----------



## deepthroat (25. Februar 2009)

Hi.

Warum hast du denn dort überall "-o -g" drin stehen? Also, wozu das "-o"? Meintest du evlt. "-O"? Und evtl. solltest du den CMAKE_BUILD_TYPE mal auf Debug setzen...

Gruß


----------



## Der Wolf (25. Februar 2009)

Hmm ... keine Chance. Ich habe jetzt einmal das  -o durch -O ersetzt und den Parameter einmal komplett weg gelassen. CMAKE_BUILD_TYPE steht dabei die ganze Zeit auf Debug aber ich bekomme durch gdb trotzdem nur Ausgaben wie die folgende:


```
#12 0xb730f135 in xmltio::Location::operator[] (this=0xbfdb0f30, 
    xpath=@0xbfdb0f48) at Location.cpp:155
---Type <return> to continue, or q <return> to quit---
#13 0xb730ff1c in Location (this=0xbfdb1088, xml=@0xbfdb10ec, 
    xpath=@0xbfdb10e0) at Location.cpp:86
#14 0x080999de in FaceAnchor::getDocument ()
#15 0x0809813f in AnchorList::updateActiveMemory ()
#16 0x0809b181 in FaceAnchorList::updateAnchors ()
#17 0x0806c6fb in main ()
```

Dabei wäre wirklich interessant, wo genau der Fehler in der getDocument() autaucht.


----------



## deepthroat (25. Februar 2009)

Hi.

Probier mal die -gdwarf-2 Option wegzulassen.

Gruß


----------



## Der Wolf (25. Februar 2009)

Steht nicht mehr drin, genauso wenig die das -O ... funktioniert trotzdem nicht.


----------



## deepthroat (25. Februar 2009)

Der Wolf hat gesagt.:


> Steht nicht mehr drin, genauso wenig die das -O ... funktioniert trotzdem nicht.


Hm. Und du hast alles nochmal neu kompiliert?


----------



## Der Wolf (25. Februar 2009)

Korrekt. Leider hat es zu keinen neuen Ergebnissen geführt


----------



## deepthroat (25. Februar 2009)

Wieso sieht eigentlich die Ausgabe so komisch aus? Kann es sein, das das Programm irgendwas mit dem Terminal macht, so dass man einfach die Ausgabe vom gdb nicht sieht? Hast du mal ddd probiert?


----------



## Der Wolf (25. Februar 2009)

Ehrlich gesagt nein, dass kannte ich bis gerade noch nicht einmal :-(


----------



## Der Wolf (25. Februar 2009)

Also ich hab jetzt nochmal rumgegooglet und gesehen dass bei einem anderen, der so ähnliche Probeme hatte wie ich und dem hat man geraten in sein Makefile

%.o: 
$(CXX) $(CXXFLAGS) -c $< 

ein zu tragen. Scheint aber auch nicht zu helfen. Egal was ich an flags setze, gdb sagt nachher immer  "no debug symbols found".


----------



## deepthroat (25. Februar 2009)

Der Wolf hat gesagt.:


> Egal was ich an flags setze, gdb sagt nachher immer  "no debug symbols found".


Ach, das sagst du jetzt.

Dann scheinen die Symbole ge-strip-t wordern zu sein... ? Was sagt* file* dazu?

Hast du irgendwo die Option -s bei den Linkerflags?

Gruß


----------



## Der Wolf (25. Februar 2009)

Bisher hatte ich die Option -s nirgends gesetzt gehabt. Jetzt habe ich sie mal gesetzt, geändert hat sich allerdings nichts. Und file liefert folgendes:

~: file PSystems 
PSystems: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped


Übrigens. Bevor ich es vergesse. Vielen Dank schonmal für deine Geduld. Ich merke jeden Tag aufs neue dass mir doch noch immer einiges an Erfahrung abgeht. :-(


----------



## deepthroat (25. Februar 2009)

Der Wolf hat gesagt.:


> Bisher hatte ich die Option -s nirgends gesetzt gehabt. Jetzt habe ich sie mal gesetzt, geändert hat sich allerdings nichts.


Diese Option darf nicht gesetzt sein, sonst werden die Debugging Informationen entfernt (gestript).


Der Wolf hat gesagt.:


> ~: file PSystems
> PSystems: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), *stripped*


Ja, die Datei hat keine Debugging Symbole mehr.


Der Wolf hat gesagt.:


> Übrigens. Bevor ich es vergesse. Vielen Dank schonmal für deine Geduld.


Ja, kein Problem. Aber so langsam fällt mir auch nichts mehr ein.

Setz doch einfach mal das CMAKE_STRIP Programm auf "true", so dass "/usr/bin/strip" nicht aufgerufen wird. (bzw. schau mal in der Log Datei ob strip aufgerufen wurde)

Gruß


----------



## Der Wolf (25. Februar 2009)

CMAKE_STRIP auf true gesetzt ... und und und ... aber die Datei ist immernoch stripped markiert -.-

Ich gebe es auf und versuche weiterhin es auf den Weg über viele std::cout zu finden.

Nochmals Danke. Falls du noch Ideen haben solltest immer her damit. Aber da du ja eben meintest sie gehen dir langsam aus, nehme ich mal an du hast auch keine mehr.


----------



## Der Wolf (27. Februar 2009)

So. Mittlerweile hat mir jemand zeigen können woran es liegt. Ist mir zwar etwas peinlich aber naja ... in der CMakeList.txt wurden per pkg-config Macro einige Bibliotheken dazu gelinkt und in zweien davon war ein -s Flag gesetzt. So was blödes.


----------

