Re: python25 core dumps
On Thursday 15 November 2007 03:07:03 am Heiko Wundram (Beenic) wrote: > This seems like a problem in qt4 (I don't think the problem is in PyQt), > simply try reinstalling that, too (completely; qt4 is split into several > ports and "pkg_info | grep qt4" is your friend here). A complete rebuild of qt4-* did not solve the problem, however, a complete rebuild of py25-qt4* solved everything. (Except the Gtk problems, naturally) Apparently there was something in the pre-built packages that didn't agree with my machine. I'm hoping that a rebuild of all dependencies for gramps will solve the problems there as well. David -- If this message was not entertaining, write your congressman. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: python25 core dumps
On Thursday 15 November 2007 03:07:03 am Heiko Wundram (Beenic) wrote: > This seems like a problem in libaspell; maybe you should simply try to > reinstall the aspell port. See below for more info. I rebuilt aspell, but gramps still core dumps. The backtrace shows the same as previously. :/ > > For comparison, this is what a crash from eric4 (built with PyQt4) looks > > like: > This seems like a problem in qt4 (I don't think the problem is in PyQt), > simply try reinstalling that, too (completely; qt4 is split into several > ports and "pkg_info | grep qt4" is your friend here). > > Generally, from what I interpret into the second backtrace, you upgraded > from some 6 release to 7.0-BETA2, which (amongst other things) means that > the C++ libraries have changed (because of a newer compiler, gcc 3.3 vs. > 4.2). The compiler has also had changes introduced to the C++ type info > descriptor layout (which I should think causes the segmentation fault in > typeinfo name in the second backtrace), so that if you have a program > that's linked against different versions of libstdc++ (PyQt is linked > against that, just as qt4 is), you'll see behaviour like this. > > To check whether my hypothesis is correct, simply do an ldd on both a PyQt > library, and a qt4 shared library (locations of both of which you can > extract from the backtrace). If the version of libstdc++ is different, you > didn't follow the upgrading procedure which explicitly states to recompile > _all_ ports for the new system. These appear to be the same, but its possible my blurry eyes may be overlooking something obvious. /usr/local/lib/libQtGui.so.4: libpng.so.5 => /usr/local/lib/libpng.so.5 (0x28185000) libSM.so.6 => /usr/local/lib/libSM.so.6 (0x281aa000) libICE.so.6 => /usr/local/lib/libICE.so.6 (0x281b2000) libQtCore.so.4 => /usr/local/lib/libQtCore.so.4 (0x28a1a000) libz.so.4 => /lib/libz.so.4 (0x281c9000) libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x281db000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28b89000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28c27000) libXi.so.6 => /usr/local/lib/libXi.so.6 (0x281e) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x281e8000) libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x281f) libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x281f7000) libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x28d1c000) libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x281fc000) libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x28d25000) libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x28d93000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x28dbd000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x28dcb000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28eb8000) libm.so.5 => /lib/libm.so.5 (0x28fa2000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x28fb7000) libthr.so.3 => /lib/libthr.so.3 (0x28fc2000) libc.so.7 => /lib/libc.so.7 (0x28089000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28fd4000) libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28fdd000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x29003000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x29023000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x29026000) librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x2902b000) /usr/local/lib/python2.5/site-packages/PyQt4/QtGui.so: libQtGui.so.4 => /usr/local/lib/libQtGui.so.4 (0x28b09000) libpng.so.5 => /usr/local/lib/libpng.so.5 (0x28185000) libSM.so.6 => /usr/local/lib/libSM.so.6 (0x281aa000) libICE.so.6 => /usr/local/lib/libICE.so.6 (0x281b2000) libQtCore.so.4 => /usr/local/lib/libQtCore.so.4 (0x29223000) libz.so.4 => /lib/libz.so.4 (0x281c9000) libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x281db000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x29392000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2943) libXi.so.6 => /usr/local/lib/libXi.so.6 (0x281e) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x281e8000) libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x281f) libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x281f7000) libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x29525000) libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x281fc000) libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x2952e000) libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x2959c000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x295c6000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x295d4000) libm.so.5 => /lib/libm.so.5 (0x296c1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x296d6000) libgcc_s.so.1
Re: python25 core dumps
Am Donnerstag, 15. November 2007 04:07:26 schrieb David J Brooks: > Ok. Here's what gdb shows for a crash from Gramps (built with py-Gtk2): > > (gdb) back > #0 0x29ea37fd in delete_aspell_speller () from > /usr/local/lib/libaspell.so.16 #1 0x29e03b3d in > gtkspell_set_language_internal () > from /usr/local/lib/libgtkspell.so.0 > #2 0x29e04084 in gtkspell_set_language () > from /usr/local/lib/libgtkspell.so.0 > #3 0x29af90ae in ?? () > from /usr/local/lib/python2.5/site-packages/gtk-2.0/gtkspell.so > #4 0x29cdf180 in ?? () > #5 0x29d28ff4 in ?? () > #6 0x in ?? () > #7 0xbfbf5218 in ?? () > #8 0xbfbf5220 in ?? () > #9 0x29d284cc in ?? () > #10 0x29af9681 in ?? () > from /usr/local/lib/python2.5/site-packages/gtk-2.0/gtkspell.so > #11 0x in ?? () > #12 0x29d28ff4 in ?? () > #13 0x28308080 in ?? () > #14 0xbfbf53c8 in ?? () > #15 0x080b131a in PyEval_EvalFrameEx () > Previous frame identical to this frame (corrupt stack?) > (gdb) This seems like a problem in libaspell; maybe you should simply try to reinstall the aspell port. See below for more info. > For comparison, this is what a crash from eric4 (built with PyQt4) looks > like: > > (gdb) back > #0 0x29224448 in typeinfo name for sipQApplication () >from /usr/local/lib/python2.5/site-packages/PyQt4/QtGui.so > #1 0x29595531 in sm_performSaveYourself () from > /usr/local/lib/libQtGui.so.4 #2 0x295956a1 in sm_saveYourselfCallback () > from /usr/local/lib/libQtGui.so.4 #3 0x29aed10b in _SmcProcessMessage () > from /usr/local/lib/libSM.so.6 #4 0x29afffa3 in IceProcessMessages () from > /usr/local/lib/libICE.so.6 #5 0x2958f5c8 in > QSmSocketReceiver::socketActivated () > from /usr/local/lib/libQtGui.so.4 > #6 0x2958f62f in QSmSocketReceiver::qt_metacall () > from /usr/local/lib/libQtGui.so.4 > #7 0x287bc15f in QMetaObject::activate () from > /usr/local/lib/libQtCore.so.4 #8 0x287bc6d2 in QMetaObject::activate () > from /usr/local/lib/libQtCore.so.4 #9 0x287d8b33 in > QSocketNotifier::activated () > from /usr/local/lib/libQtCore.so.4 > #10 0x287c1e1f in QSocketNotifier::event () from > /usr/local/lib/libQtCore.so.4 #11 0x295467bd in > QApplicationPrivate::notify_helper () > from /usr/local/lib/libQtGui.so.4 > #12 0x2954c8fe in QApplication::notify () from /usr/local/lib/libQtGui.so.4 > #13 0x291b4a13 in sipQApplication::notify () > from /usr/local/lib/python2.5/site-packages/PyQt4/QtGui.so > #14 0x287ab07b in QCoreApplication::notifyInternal () > from /usr/local/lib/libQtCore.so.4 > #15 0x287ccaf3 in socketNotifierSourceDispatch () > from /usr/local/lib/libQtCore.so.4 > #16 0x28852886 in g_main_context_dispatch () > from /usr/local/lib/libglib-2.0.so.0 > #17 0x28855c02 in g_main_context_check () from > /usr/local/lib/libglib-2.0.so.0 #18 0x28856185 in g_main_context_iteration > () > from /usr/local/lib/libglib-2.0.so.0 > #19 0x287ccf78 in QEventDispatcherGlib::processEvents () > from /usr/local/lib/libQtCore.so.4 > #20 0x295bd965 in QGuiEventDispatcherGlib::processEvents () > from /usr/local/lib/libQtGui.so.4 > #21 0x287aac31 in QCoreApplication::processEvents () > from /usr/local/lib/libQtCore.so.4 > #22 0x28623966 in meth_QCoreApplication_processEvents () >from /usr/local/lib/python2.5/site-packages/PyQt4/QtCore.so > #23 0x080b131a in PyEval_EvalFrameEx () > #24 0x080b1fab in PyEval_EvalFrameEx () > #25 0x080b1fab in PyEval_EvalFrameEx () > #26 0x080b2919 in PyEval_EvalCodeEx () > #27 0x080b2a67 in PyEval_EvalCode () > #28 0x080c9fc6 in Py_CompileString () > #29 0x080ca070 in PyRun_FileExFlags () > #30 0x080cb569 in PyRun_SimpleFileExFlags () > #31 0x08056ef1 in Py_Main () > #32 0x080563b5 in main () > (gdb) This seems like a problem in qt4 (I don't think the problem is in PyQt), simply try reinstalling that, too (completely; qt4 is split into several ports and "pkg_info | grep qt4" is your friend here). Generally, from what I interpret into the second backtrace, you upgraded from some 6 release to 7.0-BETA2, which (amongst other things) means that the C++ libraries have changed (because of a newer compiler, gcc 3.3 vs. 4.2). The compiler has also had changes introduced to the C++ type info descriptor layout (which I should think causes the segmentation fault in typeinfo name in the second backtrace), so that if you have a program that's linked against different versions of libstdc++ (PyQt is linked against that, just as qt4 is), you'll see behaviour like this. To check whether my hypothesis is correct, simply do an ldd on both a PyQt library, and a qt4 shared library (locations of both of which you can extract from the backtrace). If the version of libstdc++ is different, you didn't follow the upgrading procedure which explicitly states to recompile _all_ ports for the new system. Output should look something like this, anyway: [EMAIL PROTECTED] ~]$ ldd /usr/local/lib/libqt-mt.so.3 /usr/local/lib/libqt-mt.so.3: ... libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28c4c000) ... [EMAIL PROTECTE
Re: python25 core dumps
On Wednesday 14 November 2007 05:57:52 pm Heiko Wundram (Beenic) wrote: > Am Mittwoch, 14. November 2007 23:15:36 schrieb David J Brooks: > > Since upgrading to 7.0-BETA2 most of my python based programs fail with > > Segmentation fault: 11 (core dumped). It seems to be limited to gui based > > programs using Gtk or Qt. Any idea what's going on there? Hints on how to > > analyze the python.core files would be helpful too. > > Easy way to get info from the backtrace: > > gdb /usr/local/bin/python /python.core > > Then, enter the "back" command in the post-mortem debugging session and > post the output here. Someone (maybe even me) should be able to give you a > hint where to look further from there. Ok. Here's what gdb shows for a crash from Gramps (built with py-Gtk2): (gdb) back #0 0x29ea37fd in delete_aspell_speller () from /usr/local/lib/libaspell.so.16 #1 0x29e03b3d in gtkspell_set_language_internal () from /usr/local/lib/libgtkspell.so.0 #2 0x29e04084 in gtkspell_set_language () from /usr/local/lib/libgtkspell.so.0 #3 0x29af90ae in ?? () from /usr/local/lib/python2.5/site-packages/gtk-2.0/gtkspell.so #4 0x29cdf180 in ?? () #5 0x29d28ff4 in ?? () #6 0x in ?? () #7 0xbfbf5218 in ?? () #8 0xbfbf5220 in ?? () #9 0x29d284cc in ?? () #10 0x29af9681 in ?? () from /usr/local/lib/python2.5/site-packages/gtk-2.0/gtkspell.so #11 0x in ?? () #12 0x29d28ff4 in ?? () #13 0x28308080 in ?? () #14 0xbfbf53c8 in ?? () #15 0x080b131a in PyEval_EvalFrameEx () Previous frame identical to this frame (corrupt stack?) (gdb) For comparison, this is what a crash from eric4 (built with PyQt4) looks like: (gdb) back #0 0x29224448 in typeinfo name for sipQApplication () from /usr/local/lib/python2.5/site-packages/PyQt4/QtGui.so #1 0x29595531 in sm_performSaveYourself () from /usr/local/lib/libQtGui.so.4 #2 0x295956a1 in sm_saveYourselfCallback () from /usr/local/lib/libQtGui.so.4 #3 0x29aed10b in _SmcProcessMessage () from /usr/local/lib/libSM.so.6 #4 0x29afffa3 in IceProcessMessages () from /usr/local/lib/libICE.so.6 #5 0x2958f5c8 in QSmSocketReceiver::socketActivated () from /usr/local/lib/libQtGui.so.4 #6 0x2958f62f in QSmSocketReceiver::qt_metacall () from /usr/local/lib/libQtGui.so.4 #7 0x287bc15f in QMetaObject::activate () from /usr/local/lib/libQtCore.so.4 #8 0x287bc6d2 in QMetaObject::activate () from /usr/local/lib/libQtCore.so.4 #9 0x287d8b33 in QSocketNotifier::activated () from /usr/local/lib/libQtCore.so.4 #10 0x287c1e1f in QSocketNotifier::event () from /usr/local/lib/libQtCore.so.4 #11 0x295467bd in QApplicationPrivate::notify_helper () from /usr/local/lib/libQtGui.so.4 #12 0x2954c8fe in QApplication::notify () from /usr/local/lib/libQtGui.so.4 #13 0x291b4a13 in sipQApplication::notify () from /usr/local/lib/python2.5/site-packages/PyQt4/QtGui.so #14 0x287ab07b in QCoreApplication::notifyInternal () from /usr/local/lib/libQtCore.so.4 #15 0x287ccaf3 in socketNotifierSourceDispatch () from /usr/local/lib/libQtCore.so.4 #16 0x28852886 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #17 0x28855c02 in g_main_context_check () from /usr/local/lib/libglib-2.0.so.0 #18 0x28856185 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #19 0x287ccf78 in QEventDispatcherGlib::processEvents () from /usr/local/lib/libQtCore.so.4 #20 0x295bd965 in QGuiEventDispatcherGlib::processEvents () from /usr/local/lib/libQtGui.so.4 #21 0x287aac31 in QCoreApplication::processEvents () from /usr/local/lib/libQtCore.so.4 #22 0x28623966 in meth_QCoreApplication_processEvents () from /usr/local/lib/python2.5/site-packages/PyQt4/QtCore.so #23 0x080b131a in PyEval_EvalFrameEx () #24 0x080b1fab in PyEval_EvalFrameEx () #25 0x080b1fab in PyEval_EvalFrameEx () #26 0x080b2919 in PyEval_EvalCodeEx () #27 0x080b2a67 in PyEval_EvalCode () #28 0x080c9fc6 in Py_CompileString () #29 0x080ca070 in PyRun_FileExFlags () #30 0x080cb569 in PyRun_SimpleFileExFlags () #31 0x08056ef1 in Py_Main () #32 0x080563b5 in main () (gdb) I tried tovidgui (build with Tkinter) and it did not crash. David -- Federal law prohibits deleting this message. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: python25 core dumps
On Thu, 15 Nov 2007 00:57:52 +0100
"Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 14. November 2007 23:15:36 schrieb David J Brooks:
> > Since upgrading to 7.0-BETA2 most of my python based programs fail with
> > Segmentation fault: 11 (core dumped). It seems to be limited to gui based
> > programs using Gtk or Qt. Any idea what's going on there? Hints on how to
> > analyze the python.core files would be helpful too.
>
> Easy way to get info from the backtrace:
>
> gdb /usr/local/bin/python /python.core
>
> Then, enter the "back" command in the post-mortem debugging session and post
> the output here. Someone (maybe even me) should be able to give you a hint
> where to look further from there.
same happens here with castpodder (which is a gtk/python tool), but i havent
been able to find a .core . I need to look into a ktrace and step into the code
with pydev in eclipse.
B
_
{Beto|Norberto|Numard} Meijome
You shouldn't verb words.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: python25 core dumps
Am Mittwoch, 14. November 2007 23:15:36 schrieb David J Brooks: > Since upgrading to 7.0-BETA2 most of my python based programs fail with > Segmentation fault: 11 (core dumped). It seems to be limited to gui based > programs using Gtk or Qt. Any idea what's going on there? Hints on how to > analyze the python.core files would be helpful too. Easy way to get info from the backtrace: gdb /usr/local/bin/python /python.core Then, enter the "back" command in the post-mortem debugging session and post the output here. Someone (maybe even me) should be able to give you a hint where to look further from there. -- Heiko Wundram Product & Application Development ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
