3. Mir Unerklärliches Signal11/SegmentationFault

Mir Unerklärliches Signal11/SegmentationFault

  • I

    tixmldocument ist doch nicht global, sondern funktionslokal,
    und ja sie wird beim verlassen dieser funktion zerstört.

    weiters wär interessant zu schauen was genau in tinyxml.h zeile 1375 dort zerstört wird.

    #4 0x805ae2d ~TiXmlDocument(this=0xbfb6025c) (/home/darthdespotism/dev/Editor/Editor/tinyxml.h:1375)

    schonmal probiert to_parse als const referenz zu übergeben ?

    void WD::make_parse(std::string const& to_parse)
    0
  • D

    jop das Document ist nicht global, aber im "globalen", größten Block der funktion und nach meinen debuggerergebnissen wird es schon vor verlassen der funktion zerstört.

    TinyXML.h Zeile 1375:

    virtual ~TiXmlDocument() {}
    0
  • G

    Mach bitte mal in Zeile 23 eine Testausschrift.

    Aus dem Stacktrace ist deutlich ersichtich dass gerade ~TiXmlDocument destruiert wird; also knallt's bei der letzten schliessenden Klammer - für die vorletzte sollte gar keinen Code erzeugt werden.

    Das liest sich sonst ja rcht einfach; es knallt bei der Freigabe des internen Puffers eines std::string in ~TiXmlDocument.

    Derweiteren wird offenbar ein free für Thread-local-Storage aufgerufen (../tls/..); für mich siehrt das so aus als würde tls Memory "freed" das gar keines ist, oder das TLS-Segmant sei nicht korekt initialisiert worden.
    Fehlt da vielleicht irgendein init() für die TinyXML-RT ?

    Grüsse

    *this

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

    0
  • C
    Mod

    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.

    0
  • G

    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

    0
  • D

    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)

    0
  • G

    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

    0
  • D

    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

    0
  • G

    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

    0
  • D

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

    0
  • G

    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

    0
  • D

    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

    0
  • G

    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

    0
  • D
     

    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?

    0
  • G

    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

    0
  • D

    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. 👍

    0
  • G

    [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

    0
  • D

    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

    0
  • G

    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

    0
  • D

    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 😃

    0
Anmelden zum Antworten