3. Mir Unerklärliches Signal11/SegmentationFault

Mir Unerklärliches Signal11/SegmentationFault

  • 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