Seite 1 von 1
QFileBrowser - was mache ich falsch?
Verfasst: 24. Juni 2009 18:45
von D.Cent
Früher ging dieser Code hier mal, aber seit ein paar Qt-Updates nicht mehr. Ist das mein Fehler? (Korrekt gelinked, OpenSuSE Linux 11.1, Qt 4.5.1)
Code: Alles auswählen
QString filename = QFileDialog::getOpenFileName(
this,
"Open D3M-file", dir.c_str(),
"Descent3 Mods (*.d3m *.D3M)"
);
"dir" existiert und auf Windows läuft der Code auch ohne Absturz, doch auf Linux kommt ein SIGSEGV ( =Speicherzugriffsfehler ), noch bevor sich irgend ein Dialog öffnet.
Dabei kommt folgender Output:
Code: Alles auswählen
(20684) findLibraryInternal: plugins should not have a 'lib' prefix: "libkfilemodule.so"
(20684) KPluginLoader::load: The plugin "libkfilemodule" doesn't contain a kde_plugin_verification_data structure
/home/philipp/bin/d_start.sh: line 9: 20684 Speicherzugriffsfehler ./qd321go -p D.Cent
Valgrind und GDB liefern nichts sinnvolles, bin da schon alles durch.
Jemand eine Idee?
Verfasst: 24. Juni 2009 20:25
von solarix
das sind viel zu wenig Infos.. Es ist nicht mal klar, ob die Ausgabe von deinem oder einem anderen Programm des Shellscripts stammt.. Obwohl der Crash prinzipiell auch von deinem Code stammen kann (nur weil es früher lief heisst es nicht, dass der Code ok ist), würde ich trotzdem mal die Ausgabe von
$ ldd qd321go
prüfen... da dürfen nur Qt 4.5.1 Libraries aufgeführt werden..
Verfasst: 24. Juni 2009 20:34
von D.Cent
Naja ok, lassen wir das Shellscript mal weg, dann sind die 2 oberen Zeilen trotzdem da - kommen von KDE, nicht von mir. Dritte Zeile wäre dann "Speicherzugriffsfehler".
LDD hilft dabei leider nicht viel, da nur die Major-Version angezeigt wird "4". Aber auf jeden Fall sind alle Libraries bekannt.
LDD-Ausgabe:
Code: Alles auswählen
linux-gate.so.1 => (0xffffe000)
libodf.so => /home/philipp/cprogs/ODF/libodf/libodf.so (0xb7f99000)
libunzip.so => /home/philipp/cprogs/ODF/d321go_new/libunzip/libunzip.so (0xb7f8b000)
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb75a1000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7577000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb74f6000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb74ed000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb74d2000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb74c8000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb74c0000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb74ba000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb74ae000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb74aa000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7479000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7468000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7335000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb70f9000)
libz.so.1 => /lib/libz.so.1 (0xb70e3000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb70dd000)
librt.so.1 => /lib/librt.so.1 (0xb70d3000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb700e000)
libdl.so.2 => /lib/libdl.so.2 (0xb7009000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6fef000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6efa000)
libm.so.6 => /lib/libm.so.6 (0xb6ed1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ec2000)
libc.so.6 => /lib/libc.so.6 (0xb6d66000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb6d60000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb6d37000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6d33000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6d30000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6d12000)
libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb6cdf000)
/lib/ld-linux.so.2 (0xb7fb3000)
"libodf" und "libunzip" sind eigens geschriebene Libraries, können aber nicht der Auslöser sein.
Die Binary komplett zu erneuern hat dabei leider nichts gebracht (also, alles neu kompilieren).
Der Fehler tritt überall auf, egal, wo ich den Code in meinem Projekt einfüge. In einem kleinen Testprogramm sowie in nativen KDE-Programmen gibt es jedoch keine Probleme.
Verfasst: 24. Juni 2009 21:12
von upsala
Könnte es sein, daß du ein generelles Problem mit deinem Rechner hast? Du schreibst ja nicht daß erste mal von einem Speicher-Problemen...
Verfasst: 24. Juni 2009 21:32
von D.Cent
Naja, eigentlich nicht - nur eigens geschriebene Programme haben Probleme - eine Zeit lang war der besagte Absturz nur, nachdem ich Phonon benutzt habe - aber jetzt passiert das in 100% der Fälle.
Alles andere funktioniert - ich schau mal, ob das an KDE4 liegt, melde mich dann wieder.
Verfasst: 24. Juni 2009 22:06
von solarix
Woher wohl diese KDE-Meldungen kommen? Ldd sieht doch ganz vernünftig aus (ausser, dass der Defaultinstallationspfad ab Qt-Source /usr/local/... ist, nicht /usr/lib).. was hast du denn für eine Ausgabe mit "env | grep QT"? Hast du evt. einen schrägen QT_PLUGIN_PATH?
Verfasst: 24. Juni 2009 22:13
von D.Cent
Die Ausgabe ist:
Code: Alles auswählen
QTDIR=/usr/lib/qt3
QT_IM_MODULE=xim
QT_SYSTEM_DIR=/usr/share/desktop-data
QT_PLUGIN_PATH=/home/philipp/.kde4/lib/kde4/plugins/:/usr/lib/kde4/plugins/
QT_IM_SWITCHER=imsw-multi
Das mit dem Plugin-Path könnte vielleicht sogar sein - habe das .kde4-Verzeichnis schon seit 2 SuSE-Versionen.
Vielleicht wäre es sinnvoll, mal einen 2t-User anzulegen und zu schauen, ob der Fehler da auch auftritt...
EDIT: Ich habe Qt3 und 4 parallel installiert - deswegen wundert es mich, dass dort oben sowohl qt3 als auch kde4 zu sehen ist.
Verfasst: 24. Juni 2009 22:22
von D.Cent
Weder neuer User noch KDE3 bringen eine Änderung
Verfasst: 24. Juni 2009 22:26
von solarix
arg.. gar nicht schön... versuch doch mal, in deinem Shellscript vor dem Aufruf der Executable die Environment sauber aufzusetzen.. Die Qt4.5-Libraries sollte die Binary selbst finden (die Pfade sind IMHO mit -rpath fix reingelinkt). Lösche ("unset xy") doch einfach mal alle QT-Variabeln und setze lediglich QT_PLUGIN_PATH auf den Plugin-Pfad deiner Qt4.5-Installation...
Verfasst: 25. Juni 2009 20:34
von D.Cent
Ändert leider auch nichts an der Sache. Vielleicht hat es wirklich was mit "libkfilemodule.so" zu tun, doch die Version der Datei ist korrekt.
Verfasst: 26. Juni 2009 22:32
von D.Cent
Habe das ganze jetzt mal statisch gelinkt und so geht es - die Frage ist, warum?
