Seite 1 von 1
SuSE 8,1 Python mit QT crasht
Verfasst: Sonntag 20. Oktober 2002, 20:05
von hans
SuSE 8.1, PytHon mit QT crasht.
Kann kein Python mit QT starten. Beim Versuch die grafische Oberfläche zu starten, crasht das Programm.
Code: Alles auswählen
hans@poorbill:~/Projects/py/Tutorial/NorPyQt3> norpyqt3.py
Speicherzugriffsfehler
Gilt für alten als auch für neu erstellten Code. Ich weiß natürlich mal wieder nicht wo ich anfangen soll, aber liste ich doch mal alles bekannte und unbekannte auf:
- QT3 ist iunstalliert (auch wegen KDE 3.03)
- QT2 ist auch installiert. Wofür? Yast?
- gibt's ne Chance, an einen genaueren Fehlercode zu kommen
- python -d bringt nix
Installierte Paket Versionen:
Code: Alles auswählen
qt3-3.0.5-64
yast2-qt-2.6.22-0
qt3-devel-3.0.5-64
qt3-devel-doc-3.0.5-64
qt3-devel-tools-3.0.5-81
qt3-devel-tutorial-3.0.5-81
qt3-man-3.0.5-81
qt-2.3.2-286
python-2.2.1-45
python-demo-2.2.1-45
python-doc-pdf-2.2.1-45
python-mysql-0.9.1-292
pychecker-0.8.11-65
python-tk-2.2.1-45
python-imaging-1.1.3-36
python-devel-2.2.1-45
python-gtk-1.4.2-380
python-xml-2.2.1-45
PyQt-3.3.2-49
pyweblib-1.1.0-203
pyxml-0.8-30
Dann habe ich da gesehen, daß ich in meinen Umgebungsvariablen was machen könnte. Die sind bis jetzt leer.
Code: Alles auswählen
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : ':'-separated list of directories prefixed to the
default module search path. The result is sys.path.
PYTHONHOME : alternate <prefix> directory (or <prefix>:<exec_prefix>).
The default module search path uses <prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements (Windows).
Ich denke, über PythonPath könnte man ne ganze Menge (über-) steuern.
Wer hat ne Idee?
Hans
Re: SuSE 8,1 Python mit QT crasht
Verfasst: Dienstag 22. Oktober 2002, 10:42
von joerg
Hallo hans,
Du kannste einen Debugger benutzen, um eine Idee der Fehlerquelle zu bekommen, ob Du damit was anfangen kannst, weiß ich allerdings nicht.
Aufruf:
$ gdb python
Am gdb-prompt dann das Skript aufrufen:
(gdb) run meinskript.py
Wenn dann ein Absturz gemeldet wurde, kann man mit "backtrace" die Absturzgeschichte ermitteln:
(gdb) backtrace
Ganz oben steht dann die Übeltäterfunktion, darunter die Funktionen, aus der sie gerufen wurde.
Damit kannst Du z.B. rausfinden, ob der Speicherzugriffsfehler eher in Python oder in Qt begründet ist...
Tschö
Jörg
Verfasst: Dienstag 22. Oktober 2002, 22:35
von hans
Don't never change a running System.......
Wie wahr! Also wenn ich verschiedene Quellen richtig interpretiere, dann ist das ein Prob des Compilers. Der aktuelle ist gcc-3.2 Es sind aber noch Programme in der Distri, die mit der Vorversion compiliert wurden und die können scheinbar nicht so richtig miteinander. Mist..... Quelle:
www.trolltech.com und andere
QT gehört jedenfalls auch dazu. Eigentlich wollte ich QT nicht selbst comilieren. Da habe ich noch keine (gute) Efahrung. Wenn mal was lief war das eher die Azsnahme
Mein Fehlerprotokoll sieht dann übrigens so aus:
Code: Alles auswählen
(gdb) run norpyqt3.py
Starting program: /usr/bin/python2.2 norpyqt3.py
(no debugging symbols found)...(no debugging symbols found)...[New Thread 1024 (LWP 1934)]
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1934)]
0x4002d0cd in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) backtrace
#0 0x4002d0cd in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x400cf628 in free () from /lib/libc.so.6
#2 0x412b7037 in _XimCheckIfLocalProcessing () from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#3 0x412b68a9 in _XimOpenIM () from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#4 0x40830b98 in _XDynamicOpenIM () from /usr/X11R6/lib/libX11.so.6
#5 0x412b60bf in _XimRegisterIMInstantiateCallback () from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#6 0x40830cc6 in _XDynamicRegisterIMInstantiateCallback () from /usr/X11R6/lib/libX11.so.6
#7 0x40810548 in XRegisterIMInstantiateCallback () from /usr/X11R6/lib/libX11.so.6
#8 0x40302246 in qt_init_internal(int*, char**, _XDisplay*, unsigned long, unsigned long) () from /usr/lib/qt3//lib/libqt-mt.so.3
#9 0x4030389e in qt_init(int*, char**, QApplication::Type) () from /usr/lib/qt3//lib/libqt-mt.so.3
#10 0x40364dc0 in QApplication::construct(int&, char**, QApplication::Type) () from /usr/lib/qt3//lib/libqt-mt.so.3
#11 0x40364a0c in QApplication::QApplication(int&, char**) () from /usr/lib/qt3//lib/libqt-mt.so.3
#12 0x411fca50 in sipQApplication::sipQApplication(int&, char**) () from /usr/lib/python2.2/site-packages/libqtcmodule.so
#13 0x4120223d in sipNew_QApplication(_object*, _object*) () from /usr/lib/python2.2/site-packages/libqtcmodule.so
#14 0x4001b4f0 in sipCallCtor () from /usr/lib/python2.2/site-packages/libsip.so
#15 0x40ea0b09 in callCtor(_object*, _object*) () from /usr/lib/python2.2/site-packages/libqtcmodule.so
#16 0x080c6e33 in PyCFunction_Call ()
#17 0x0807826d in PyEval_EvalCode ()
#18 0x08078c4e in PyEval_EvalCodeEx ()
#19 0x080baf3c in PyFunction_SetClosure ()
#20 0x080aa857 in PyObject_Call ()
#21 0x080b146b in PyMethod_New ()
#22 0x080aa857 in PyObject_Call ()
#23 0x08079e19 in PyEval_CallObjectWithKeywords ()
#24 0x080ad3ed in PyInstance_New ()
#25 0x080aa857 in PyObject_Call ()
#26 0x0807a455 in PyEval_GetFuncDesc ()
#27 0x08078134 in PyEval_EvalCode ()
#28 0x08078c4e in PyEval_EvalCodeEx ()
#29 0x08075c35 in PyEval_EvalCode ()
#30 0x080942c9 in PyRun_FileExFlags ()
#31 0x08093253 in PyRun_SimpleFileExFlags ()
#32 0x08092b9a in PyRun_AnyFileExFlags ()
#33 0x080536ca in Py_Main ()
#34 0x08053119 in main ()
#35 0x400794a2 in __libc_start_main () from /lib/libc.so.6
(gdb)
Hans
Verfasst: Mittwoch 23. Oktober 2002, 00:29
von Dookie
Hi Hans,
versuchs mal mit Debian Woody, da is alles noch mit dem gcc2.95 oder so. Jedenfalls sollte QT da keine Probleme machen. Ich verwende ja eher Tkinter oder gtk. Bei Debian gibts mit 3.x compilierte sachen erst in der nächsten Version, wenn dann mal der Großteil läuft und keine Probs mehr macht.
Bei Problemen gibts auch ein gutes deutsches Forum unter
http://www.debianforum.de/forum/, es sind schon einige Umsteiger von Suse dort zu finden
Gruß
Dookie
Verfasst: Mittwoch 23. Oktober 2002, 11:03
von piddon
Ich weiss, ist OFFTOPIC, ABER:
Ichhabe hier jetzt auch mal Debian Woody auf meinem LAptop installiert, und muss sagen ist echt sehr, sehr gut. Die Paketverwaltung ist unschlagbar, und es ist umsonst.
Ich selbst habe vorher nur SuSe benutzt, und bin absofort geheilt
Verfasst: Mittwoch 23. Oktober 2002, 13:41
von Dookie
Naja, umsonst ist es nicht, aber kostenlos
Dookie
Verfasst: Mittwoch 23. Oktober 2002, 18:29
von hans
Ich habe hier noch ein ungebrauchtes Serverchen stehen, sollte man mal probieren.
Piddon, has du direkt vom Netz installiert?
Hans
vorsichtiger Optimismus macht sich breit
Verfasst: Mittwoch 23. Oktober 2002, 20:28
von hans
habe mal ein Bisschen gestöbert und bin bei ftp.nikoma.de auf
/pub/suse/i386/update/8.1/rpm/i586/qt3-3.0.5-85.i586.rpm gestoßen. Habs einfach mal drübergebügelt und ausprobiert. Was sehen meine Äugelchen? Et löppt....
Hätten die ja auch gleich auf die CD packen können!
Hans
Verfasst: Donnerstag 24. Oktober 2002, 08:01
von piddon
Dann hättest du aber für ein Suse8.2 bezahlen müssen.
Verfasst: Donnerstag 24. Oktober 2002, 22:27
von hans
Wie käme ich dazu? Ist doch nicht von M$
Verfasst: Freitag 25. Oktober 2002, 17:29
von piddon
Aber Suse schickt sich an, genauso zu werden. Ich finde es sogar teilweise noch schlimmer, mit eigentlich OpenSource-Prgs. ein Paket schnüren, einen YAST davor klatschen und extrem hohe Preise zu nehmen!
Vergleich mal die abstände zwischen Win2000 und WinXP, dann die Abstände zwischen den Suse-Distributionen.
Verfasst: Freitag 25. Oktober 2002, 19:43
von hans
Zu den stabilen Paketen von SuSE: No Comment, aber sehe ich mittlerweile auch so.
Das mit dem Package Preis sehe ich nicht so. Kann man natürlich drüber streiten. Du darfst aber nicht nur das OS rechnen. Du must mindestens noch Office, Corel Draw oder was auch immer noch dagegenrechnen. Das knallt rein. Mich wundert es nicht, das im privaten Bereich fast nur noch Raubkopien anzutreffen sind. Und da ein Paket auf vielen Rechnern installiert werden kann, ..........
Aber Distri hin, Distri her, wenn ich schon Geld auf den Ladentisch lege, dann erwarte ich, dass doch zumindest die Haupkomponenten sauber laufen. Und da gehört QT und gcc mit Sicherheit dazu.
Leider brauchen wir Firmen wie SuSE, sonst wird das mit der geplanten Übernahme von M$ durch Linus nix
Die MCSE brauchen was zu klicken.