Mir Unerklärliches Signal11/SegmentationFault

Gast++

camper schrieb:

Als Arbeitshypothese würde ich davon ausgehen, dass TiXmlDocument, basic_string, free etc. bug-frei sind.

Stört Dich das "tls" nicht ?
Ist das normal beim g++?

Grüsse

*this

P.S.: Hab hier grad kein *nix; deshalb frag ich so doof

darthdespotism

Gast++ schrieb:

P.S.: Das "lock" im Disassembly ist mir etwas suspekt; hast Du ein MP-System oder kompilierst Du nur mit MP-Einstellungen?

Das System ist tatsächlich SMP (C2D)

Und noch was ist mir aufgefallen, kann ich aber noch nicht unbedingt bestätigen:
Mit dem g++ 4.1.2 habe ich das Problem mit dem MinGW-Crosscompiler (3.4?) scheint der Code zu laufen, kann ich aber nicht sicher sagen, da ich kein Win zur Hand habe und GTK+ mit Wine nicht so recht funktioniert.

camper schrieb:

Als Arbeitshypothese würde ich davon ausgehen, dass TiXmlDocument, basic_string, free etc. bug-frei sind. Dann können wir schlussfolgern, dass irgendwann nach der Erzeugung von doc, etwas schiefläuft und entweder das doc Objekt oder der darin enthaltene string oder der heap selbst durch fehlerhafte Zugriffe verändert werden. Die entsprechende Stelle kriegt man durch breakpoints und Untersuchung der Daten heraus.

Alles andere wäre ja auch weltfremd.
Was genau meinst du mit den Breakpoints? Mit den Debuggern habe ich noch nicht so viel erfahrung. (Und ich habe aus meinen Brekpoints darauf geschlossen dass er beim Verlassen des if(){} Segvaulted, was eindeutig wiederlegt ist IMHO

EDIT://
Ich sehe gerade dass andere, garantiert unveränderte Programmteile beim Selben Vorgang auch Segvaullten, die auf meinem SingleCore Desktoprechner sowohl mit ubuntu/linux, wie hier auf dem Notebook, als auch unter Win problemfrei liefen.

Gut möglich dass da etwas nicht threadsafe ist. Weiß jemand wie ich das dem g++ abgewöhne (ich habe nie explizit threads verwendet in diesem Programm)

Gast++

Gib doch mal dem gcc/g++ ein -v mit und poste nur den kompletten Aufruf des Compilers für die Datei und den des Linkers.
(z.B.make 2>&1 | tee -a mylog.txt)

Über das "tls"-free komm ich irgendwie nicht hinweg!

Grüsse

*this

darthdespotism

Ok dann wirds wohl auf die Commandline gehen. C::B gibt da wohl nicht die daten zu raus.

EDIT://
Ergebniss:

Commandline:

g++ -v dlgs.cpp ed_kamp.cpp ed_param.cpp ed_ship.cpp ed-wave.cpp main.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp tinystr.cpp 
`pkg-config gtkmm-2.4 --cflags --libs` -I/usr/include/libglademm-2.4 -lglademm-2.4

Ergebniss:
Auf der Kommandline

Gast++

darthdespotism schrieb:

Ok dann wirds wohl auf die Commandline gehen. C::B gibt da wohl nicht die daten zu raus.

Wir müssen exakt die gleiche Konfig haben
=> Makefile exportieren
=> -g setzen EDIT : -v war gemeint!!! /EDIT
=> Absturz MIT DER NEUEN EXE reproduzieren!!!

Grüsse

*this

darthdespotism

also der Fehler ist reproduzierbar. Die Option makefiles zu exportieren hab ich schonmal vergeblich in C::B gesucht.

Gast++

darthdespotism schrieb:

also der Fehler ist reproduzierbar. Die Option makefiles zu exportieren hab ich schonmal vergeblich in C::B gesucht.

Wnn im Manager das Projekt selktiert ist:

"Build" => "Export Makefile"

???

Finde bitte mal gleich crt*.o unterhalb von /lib/tls

Grüsse

*this

darthdespotism

Gast++ schrieb:

"Build" => "Export Makefile"

Die Option ist vorhanden aber leider ausgegraut. Projekt ist ativ und selektiert.

Was mache ich mit den crt*.o wenn ich sie gefunden habe?

/lib/tls enthält _nur_ den Ordner i686 welcher wiederum nur cmov enthält. Darin gibts dann einige Dateien, aber keine einzige beginnt mit crt

Gast++

darthdespotism schrieb:

Gast++ schrieb:

"Build" => "Export Makefile"

Die Option ist vorhanden aber leider ausgegraut. Projekt ist ativ und selektiert.

??? => IDE Forum !

darthdespotism schrieb:

Was mache ich mit den crt*.o wenn ich sie gefunden habe?

Die Ausgabe posten...

Grüsse

*this

darthdespotism

darthdespotism@akazieLX:~/dev/Editor/Editor$ ls /lib/tls/
i686

darthdespotism@akazieLX:~/dev/Editor/Editor$ ls /lib/tls/i686
cmov

darthdespotism@akazieLX:~/dev/Editor/Editor$ ls /lib/tls/i686/cmov
ld-2.5.so               libcrypt-2.5.so  libnsl.so.1           libnss_nis-2.5.so      librt-2.5.so
ld-linux.so.2           libcrypt.so.1    libnss_compat-2.5.so  libnss_nisplus-2.5.so  librt.so.1
libanl-2.5.so           libc.so.6        libnss_compat.so.2    libnss_nisplus.so.2    libSegFault.so
libanl.so.1             libdl-2.5.so     libnss_dns-2.5.so     libnss_nis.so.2        libthread_db-1.0.so
libBrokenLocale-2.5.so  libdl.so.2       libnss_dns.so.2       libpcprofile.so        libthread_db.so.1
libBrokenLocale.so.1    libm-2.5.so      libnss_files-2.5.so   libpthread-2.5.so      libutil-2.5.so
libc-2.5.so             libmemusage.so   libnss_files.so.2     libpthread.so.0        libutil.so.1
libcidn-2.5.so          libm.so.6        libnss_hesiod-2.5.so  libresolv-2.5.so
libcidn.so.1            libnsl-2.5.so    libnss_hesiod.so.2    libresolv.so.2

Keinerlei crt*.o

Gast++ schrieb:

??? => IDE Forum !

http://www.c-plusplus.net/forum/viewtopic-var-p-is-1287956.html#1287956 OK?

Gast++

Ich meinte zwar einen richtigen "find"; keinen ls ; aber wo ich grad eine libc.co.6 sehe:

https://bugs.launchpad.net/ubuntu/+source/gawk/+bug/58256

Schau Dir mal den Stacktrace an; da knallts auch in der tls-version von free()!

Das Problem steht dort zwar als "fixed" aber wo sich der Fix nun befindet entzieht sich meiner Kenntnis.

Es gäbe vielleicht die Möglichkeit TinyXML ohne STL Nutzung zu kompilieren; im Makefile von TinyXML

TINYXML_USE_STL := NO

setzen.

Wenn ich die Ubuntu-Seite richtig verstehe müsste es eigentlich bei jedem delete eines leeren std::string knallen; Knallt's denn auch wenn Du selber einen leeren lokalen std::string verwendest?
Falls ja könntest Du das vielleicht mit einem eigenen Allokator bekämpfen.

Aber ich kann imnmer noch nicht glauben dass man dem g++ nicht das tls abgewöhnen kann ; allerdings seh ich in Deinen Compilerschaltern nichts Einschlägiges.

Grüsse

*this

darthdespotism

Ich kann TinyXML das Verwenden der STL abgewönen indem ich vor dem Inkludieren ein Makro nicht definiere. Meine ich schonmal verscuht zu haben aber ich probiers nochmal. Ebenso das mit dem leeren string.

#include <string>

int main()
{
    std::string test;
}

funktioniert genauso wie

#include <string>

int main()
{
    std::string test;
    test = "";
}

EDIT://
Wenn ich TinyXML OHNE std::string verwende (kein #define TIXML_USE_STL) funktioniert das tatsächlich.

Gast++

[quote="darthdespotism"]

#include <string>

int main()
{
    std::string test;
}

Das würde ich aber in der Methode machen wo der Fehler auftritt EDIT und zwar in einem eigen Block /EDIT; so wie ich den Stacktrace deute wird die Funktion von einem Framework(Thread) aufgerufen!

Grüsse

*this

darthdespotism

Naja erstmal bin ich glücklich da das Programm ohne STL ja läuft (es ist nicht bugfrei aber das ist ein anderes Thema )

EDIT://
Mit TinyXML ohne std::string. Das Programm setzt massiv STL ein und string gehört wohl genaugenommen gar nicht zur STL

Gast++

darthdespotism schrieb:

Mit TinyXML ohne std::string. Das Programm setzt massiv STL ein und string gehört wohl genaugenommen gar nicht zur STL

??? string ist eine Templateinstanz von basic_string die den Default-Allokator für char nutzt. Solch ein Problem wie mit free() ist dann schon ein ziemlich zentrales...

Imho etwas unbefriedigend jetzt mit einem halben Bugfix aufzuhören!

Na, ja - happy hacking anyway!

Grüsse

*this

darthdespotism

Naja wenn das wirklich daher kommt dass in TinyXML der string aus libstdc++ verwendet wird liegt das außerhalb meines Einflussbereichs, denk ich. Ein Problem in TinyXML könnte ich zur Not vll noch finden, die Stańdart bibliotek ist mir dann doch eine Nummer zu groß.

Und wenns in meinem Code wirklich sein sollte, das Ding hat ~5000 LOC, das ist schon einiges wenn das Problem sich nur im Destruktor eines Bibliotekobjekts feststellen lässt ...

Gast++ schrieb:

Na, ja - happy hacking anyway!

Danke
Auf zum nächsten Bug. Bevor der nicht behoben ist wird da nichts neues Eingebaut