Hallo, seit ich von SuSE 7.2 auf SuSE 8.1 umgestiegen bin, habe ich ein merkwürdiges Problem: Ich kann ein Programm, das ich statisch gelinkt habe, nicht mehr ausführen. Ich erhalte kurz nach dem Start immer einen Absturz wegen eines Segmentation Faults. Die Analyse des erzeugten Core Dumps ergibt folgendes Bild: (gdb) bt #0 __pthread_mutex_lock (mutex=0x410) at mutex.c:99 #1 0x089126fd in __libc_free (mem=0x410) at malloc.c:3151 #2 0x08707c21 in XFree () #3 0x083fdf5e in qstring_to_xtp(QString const&) () #4 0x083fe025 in QWidget::setCaption(QString const&) () #5 0x084e4143 in QDockWindow::setCaption(QString const&) () #6 0x0854c613 in QToolBar::setLabel(QString const&) () #7 0x0809ee2d in GenespotterBase (this=0x8f17aac, parent=0x410, name=0x3a0007e
, fl=1040) at .ui/genespotterbase.cpp:198 #8 0x0804b7ad in Genespotter (this=0x3a0007e, parent=0x410, name=0x410 , fl=1040) at genespotter.cpp:100 #9 0x0808bcbd in Application::init() (this=0x8f17aac) at application.cpp:74 #10 0x0808ba73 in Application (this=0x8f17aac) at application.cpp:59 #11 0x0808bde6 in Application::get() () at application.cpp:96 #12 0x080484a2 in main (argc=1, argv=0x3a0007e) at main.cpp:70 #13 0x088f14c7 in __libc_start_main (main=0x8048390 <main>, argc=1, ubp_av=0xbfffee44, init=0x80480b4 <_init>, fini=0x8952760 <_fini>, rtld_fini=0, stack_end=0x410) at ../sysdeps/generic/libc-start.c:129 Current language: auto; currently c Hier einige relevante Daten: - Programmiert ist das Ganze in C++. - Ich verwende den Gcc 3.2. - Die Applikation verwendet die Qt-Library in der Version 3.0.5. - Einige der Third-Party-Bibliotheken (unter anderem die Qt-Bibliothek) wurden unter SuSE 7.2 kompiliert und lediglich in das neue System übernommen. Übersetzt wurden sie allerdings ebenfalls mit dem Gcc 3.2. Die Hinweise auf "Address xyz out of bounds" habe ich natürlich bemerkt. Klar sind sie mir allerdings nicht, denn der aufgerufene Konstruktor Genespotter(parent, name, fl) erwartet zwar drei Parameter, diese werden in der Deklaration des Konstruktors aber alle mit "0" als Default-Wert initialisiert (insbesondere der "const char *"-Parameter "name"). Demzufolge wird der Konstruktor auch ohne Parameter aufgerufen. Darüberhinaus konnte ich folgende Merkwürdigkeiten beobachten: 1. Linke ich das Programm dynamisch, läuft es klaglos. 3. Das Problem betrifft auch SuSE 8.0, denn auf einem unter dieser SuSE-Version laufenden Rechner habe ich genau dasselbe Verhalten. Hat irgendjemand eine Ahnung, wo das Problem liegen könnte? Ich bin mittlerweile ziemlich ratlos. Das Einzige, was mir noch einfällt, ist, alle Bibliotheken, die ich unter SuSE 7.2 als Third-Party-Libraries kompiliert hatte, auf meinem 8.1 noch einmal zu übersetzen. Wenn möglich, würde ich das allerdings gerne vermeiden, denn das erzeugt doch eine Menge Aufwand... Vielen Dank schon mal für Eure Hilfe. Alex. -- Alexander Glintschert, MicroDiscovery GmbH Marienburger Strasse 1, D-10405 Berlin, Germany Tel.: +49-(0)30-44350900, Fax: +49-(0)30-443509010 alexander.glintschert@microdiscovery.de http://www.microdiscovery.de
Hi, On 4 Feb 2003, Alexander Glintschert wrote:
#0 __pthread_mutex_lock (mutex=0x410) at mutex.c:99
Wenn wir mal annehmen, das der mutex-Paremeter tatsache den Wert 0x410 (==1040) hat, dann ist der Absturz klar (es ist eben ein Pointer ins Nirvana). Es kann allerdings sein, das die debug-info einfach nicht ganz korrekt ausgewertet wird ...
#1 0x089126fd in __libc_free (mem=0x410) at malloc.c:3151
... und da hier ein free ebenfalls auf 0x410 gemacht wird, welches hoechstwahrscheinlich _nicht_ die Addresse der obigen mutex ist, ist dies sogar die wahrscheinlichere Variante. I.e. die debug-infos sind nicht exakt (zumindest die Belegung der Parameter), womit der Backtrace einiges an Information einbuesst.
#7 0x0809ee2d in GenespotterBase (this=0x8f17aac, parent=0x410, name=0x3a0007e
, fl=1040) at .ui/genespotterbase.cpp:198
Gegeben obiges Verhalten wuerde ich durchaus nichts auf diese von gdb herausbekommenen Werte geben. Sie sind so kaputt, das, wenn sie stimmen wuerden schon vorher ein SEGV haette passieren muessen. Z.B. ist der naechste 'this' Pointer auch im Nirvana :
#8 0x0804b7ad in Genespotter (this=0x3a0007e, parent=0x410, name=0x410
, fl=1040) at genespotter.cpp:100
Hier einige relevante Daten: - Programmiert ist das Ganze in C++. - Ich verwende den Gcc 3.2. - Die Applikation verwendet die Qt-Library in der Version 3.0.5. - Einige der Third-Party-Bibliotheken (unter anderem die Qt-Bibliothek) wurden unter SuSE 7.2 kompiliert und lediglich in das neue System übernommen. Übersetzt wurden sie allerdings ebenfalls mit dem Gcc 3.2.
Hmm. Welche Bibliotheken genau wurden aus der 7.2 genommen? Kompilierst du das Programm selbst auf der 8.x , holst die libs zum linken aber von ner 7.2? Wie statisch ist das Programm? I.e. wird irgendeine lib doch dynamisch gelinkt (z.B. libc, oder gar libpthread?). Was sagt denn ldd zu deinem executable.
Darüberhinaus konnte ich folgende Merkwürdigkeiten beobachten: 1. Linke ich das Programm dynamisch, läuft es klaglos.
Ohoh. Ohne obige Infos wuerde ich erstmal vermuten, das es entweder das Problem mit unserem malloc-Ersatz ist, oder irgendwas mit pthread. Was sagt denn "nm /path/to/libqt.a | grep malloc" ? (ich meine die Lib, welche du dazulinkst). Zwischen 7.2 und 8.x hat sich das threading geaendert, und es kann durchaus sein, das in statischen Varianten das 7.2 Verhalten einkompiliert ist, mit 8.x aber nicht mehr kompatibel ist.
Hat irgendjemand eine Ahnung, wo das Problem liegen könnte? Ich bin mittlerweile ziemlich ratlos. Das Einzige, was mir noch einfällt, ist, alle Bibliotheken, die ich unter SuSE 7.2 als Third-Party-Libraries kompiliert hatte, auf meinem 8.1 noch einmal zu übersetzen. Wenn möglich, würde ich das allerdings gerne vermeiden, denn das erzeugt doch eine Menge Aufwand...
Es waere allerdings wirklich die vernuenftigste Alternative. Ciao, Micha.
Hi,
danke für die schnelle Antwort.
Michael Matz
Hi,
On 4 Feb 2003, Alexander Glintschert wrote:
#0 __pthread_mutex_lock (mutex=0x410) at mutex.c:99
Wenn wir mal annehmen, das der mutex-Paremeter tatsache den Wert 0x410 (==1040) hat, dann ist der Absturz klar (es ist eben ein Pointer ins Nirvana). Es kann allerdings sein, das die debug-info einfach nicht ganz korrekt ausgewertet wird ...
#1 0x089126fd in __libc_free (mem=0x410) at malloc.c:3151
... und da hier ein free ebenfalls auf 0x410 gemacht wird, welches hoechstwahrscheinlich _nicht_ die Addresse der obigen mutex ist, ist dies sogar die wahrscheinlichere Variante. I.e. die debug-infos sind nicht exakt (zumindest die Belegung der Parameter), womit der Backtrace einiges an Information einbuesst.
#7 0x0809ee2d in GenespotterBase (this=0x8f17aac, parent=0x410, name=0x3a0007e
, fl=1040) at .ui/genespotterbase.cpp:198Gegeben obiges Verhalten wuerde ich durchaus nichts auf diese von gdb herausbekommenen Werte geben. Sie sind so kaputt, das, wenn sie stimmen wuerden schon vorher ein SEGV haette passieren muessen. Z.B. ist der naechste 'this' Pointer auch im Nirvana :
#8 0x0804b7ad in Genespotter (this=0x3a0007e, parent=0x410, name=0x410
, fl=1040) at genespotter.cpp:100
Hab ich fast befürchtet. Das wirft allerdings die Frage auf, womit man dann ein Debugging durchführen soll, wenn hier der gdb versagt. Ich hab nämlich eigentlich nichts Geheimnisvolles gemacht außer das Programm zu starten, seinen Core produzieren zu lassen und den dann mit dem gdb zu analysieren. Keine Ahnung, warum der damit so einen Murks anstellt...
Hier einige relevante Daten: - Programmiert ist das Ganze in C++. - Ich verwende den Gcc 3.2. - Die Applikation verwendet die Qt-Library in der Version 3.0.5. - Einige der Third-Party-Bibliotheken (unter anderem die Qt-Bibliothek) wurden unter SuSE 7.2 kompiliert und lediglich in das neue System �bernommen. �bersetzt wurden sie allerdings ebenfalls mit dem Gcc 3.2.
Hmm. Welche Bibliotheken genau wurden aus der 7.2 genommen? Kompilierst du das Programm selbst auf der 8.x , holst die libs zum linken aber von ner 7.2? Wie statisch ist das Programm? I.e. wird irgendeine lib doch dynamisch gelinkt (z.B. libc, oder gar libpthread?). Was sagt denn ldd zu deinem executable.
Die Bibliotheken wurden nicht aus dem 7.2 Release übernommen. Um eine möglichst stabile Entwicklungsumgebung hinzubekommen, haben wir die Third-Party-Bibliotheken, die wir für unsere Software brauchen, selbst kompiliert, inklusive der Qt-Bibliothek. Das geschah mit dem Gcc 3.2 unter SuSE 7.2. Diese Bibliotheken liegen nun in einem eigenen Verzeichnisbaum, der über entsprechende Makefiles beim Kompilieren verwendet wird. Als ich meine Entwicklungsumgebung unter 8.1 eingerichtet habe, habe ich demzufolge einfach alle Third-Party-Libs, die wir auf diese Weise erstellt haben, per rsync auf das 8.1-System übernommen (wieder in einen eigenen Verzeichnisbaum). Das Programm ist, soweit es den ldd betrifft, vollständig statisch. Angewendet auf das Binary erzählt er lediglich "not a dynamic executable". Allerdings scheint die Qt-Library dennoch so einige Sachen dynamisch per dlopen dazuzuholen. Das ist daran zu merken, daß ein Binary unserer Applikation, das auf einem 7.2-System gebaut wurde, auf dem 8.1 auch nicht läuft, allerdings aus einem anderen Grund, nämlich weil da ein OpenGL-Treiber dynamisch nachgeladen werden soll, was irgendwie nicht klappt. Dem Problem gehe ich aber später noch nach - eventuell melde ich dazu nochmal gesondert :-) Auf einem 8.0 funktioniert das zumindest.
Dar�berhinaus konnte ich folgende Merkw�rdigkeiten beobachten: 1. Linke ich das Programm dynamisch, l�uft es klaglos.
Ohoh. Ohne obige Infos wuerde ich erstmal vermuten, das es entweder das Problem mit unserem malloc-Ersatz ist, oder irgendwas mit pthread. Was sagt denn "nm /path/to/libqt.a | grep malloc" ? (ich meine die Lib, welche du dazulinkst). Zwischen 7.2 und 8.x hat sich das threading geaendert, und es kann durchaus sein, das in statischen Varianten das 7.2 Verhalten einkompiliert ist, mit 8.x aber nicht mehr kompatibel ist.
Unsere Qt-Library (libqt-mt.a) produziert mittels nm folgenden Output: U malloc U malloc U malloc U malloc U malloc U malloc U malloc U malloc 00000500 t _Z8memallocj 000003c0 T mng_getcb_memalloc 00000000 T mng_setcb_memalloc U malloc U png_malloc U malloc 00000080 T png_malloc U png_malloc U png_malloc U png_malloc U png_malloc U png_malloc U png_malloc U png_malloc U malloc U malloc U malloc
Es waere allerdings wirklich die vernuenftigste Alternative.
Naja, ich hatte es schon befürchtet. Ich werd's mal in einer ruhigen Minute ins Auge fassen... Gruß, Alex. -- Alexander Glintschert, MicroDiscovery GmbH Marienburger Strasse 1, D-10405 Berlin, Germany Tel.: +49-(0)30-44350900, Fax: +49-(0)30-443509010 alexander.glintschert@microdiscovery.de http://www.microdiscovery.de
participants (2)
-
Alexander Glintschert -
Michael Matz