Summary: | dev-lang/python has TFU uuid when libuuid is brought in by other extensions | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blackrabbit, cardoe, davech, gnome, igor, joost.ruis, ps, python, qt, spatz, x11, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 353224 | ||
Bug Blocks: | 366293 |
Description
Diego Elio Pettenò (RETIRED)
2011-01-17 12:15:55 UTC
I cannot reproduce: $ python -c 'import gtk, uuid; print (uuid.uuid1().hex)' ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow) ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible) ** Message: pygobject_register_sinkfunc is deprecated (GtkObject) $ echo $? 0 I have the following: [ebuild R ] dev-python/pygtk-2.17.0 USE="test -doc -examples" 0 kB [ebuild R ] x11-libs/cairo-1.10.2-r1 USE="X opengl qt4 svg xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) (-openvg) -static-libs" 0 kB I can - same cairo, but dev-python/pygtk-2.22.0. No debugging symbols, but may help anyway: #0 0xb5c4425d in uuid_generate_time () from /lib/libuuid.so.1 #1 0xb787c677 in ffi_call_SYSV () from /usr/lib/libffi.so.5 #2 0xb787c4ce in ffi_call () from /usr/lib/libffi.so.5 #3 0xb5ad1997 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so #4 0xb5acb7ba in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so #5 0xb7e7cc1a in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 #6 0xb7f148ac in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #7 0xb7f16c8f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #8 0xb7f15471 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #9 0xb7f16c8f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #10 0xb7f16dd3 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0 #11 0xb7f302db in ?? () from /usr/lib/libpython2.7.so.1.0 #12 0xb7f30f85 in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0 #13 0xb7f31c24 in PyRun_SimpleStringFlags () from /usr/lib/libpython2.7.so.1.0 #14 0xb7f43396 in Py_Main () from /usr/lib/libpython2.7.so.1.0 #15 0x080487d3 in main () Yes that the same trace I got. pygtk-2.22 is not in tree for a reason... It does not pass its testsuite as reported upstream. Also works ok for me with 2.22 :-/, maybe the problem is related by you using python-2.7? (In reply to comment #5) > Also works ok for me with 2.22 :-/, maybe the problem is related by you using > python-2.7? > No, info says 2.6.6-r1. Yes, I don't know where is the problem then :-/ Flameeyes, what pygtk version are you using? (original report doesn't shows it). Thanks I can reproduce segmentation fault with both x11-libs/cairo-1.10.2-r1[qt4] and x11-libs/cairo-1.10.2-r1[-qt4]. And what pygtk version are you running? Make sure you've been using --as-needed otherwise you need to rebuild more than just cairo[-qt4] (as QtGui, libSM and libuuid would be added to _more_ needed lists). dev-python/pygtk-2.17.0 here; problem happens both with 2.7 and 2.6 (I did downgrade thinking it was 2.7 problem). OK, the difference in ldd output between qt4 and -qt4 is that with qt4, cairo links indirectly to libuuid via libQtGui.so.4 -> libSM.so.6. But why does python throw a fit about it ? Yes that's the middle-cause of it; the root cause I don't know, it seems like Python makes a mess if libuuid is loaded before the uuid extension is imported. Zac also hit that with calibre before FWIW (if he didn't tell me about the order issue I'd never have found this problem). (In reply to comment #11) > OK, the difference in ldd output between qt4 and -qt4 is that > with qt4, cairo links indirectly to libuuid via libQtGui.so.4 -> libSM.so.6. Maybe it's a duplicate of bug 317557 since that also involves qt libraries. Sorta, the trace there is for the random uuid, this for the time uuid, so they are most definitely related but not the same issue. Perhaps the problem lies not in pygtk/PyQt4, but in a way python/ctypes loads/unloads libraries ? Fun, now it seems to break in many other ways: flame@raven ~ % python Python 2.6.6 (r266:84292, Jan 16 2011, 22:31:06) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pynotify ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow) ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible) ** Message: pygobject_register_sinkfunc is deprecated (GtkObject) >>> import uuid >>> uuid.uuid1().hex zsh: segmentation fault python so yes we have a problem here. Moving to python. Well, if you still have cairo[qt4], it may actually be exactly the same way - something bad happens if cairo linked with QtGui is opened by python. It filters through on other libraries if --as-needed is not entirely forced like I have suggested many times (as Arfrever can tell, LD_AS_NEEDED no longer works). We're going to have to look for the original problem in python's uuid. The root cause might be some TLS issues in libuuid (just taking a wild guess...) Seems the shortest way is "python -c 'import cairo, uuid; print (uuid.uuid1().hex)'". Does anyone have an idea if the patch from bug 353224 is the proper solution ? (In reply to comment #20) > Seems the shortest way is "python -c 'import cairo, uuid; print > (uuid.uuid1().hex)'". Well, as this works with glibc 2.13-r4, it most likely was the same problem as in bug 353224. Would be nice if backported to 2.12, unless 2.13-r4 is getting into stable soon. (In reply to comment #22) > (In reply to comment #20) > > Seems the shortest way is "python -c 'import cairo, uuid; print > > (uuid.uuid1().hex)'". > > Well, as this works with glibc 2.13-r4, it most likely was the same problem as > in bug 353224. > > Would be nice if backported to 2.12, unless 2.13-r4 is getting into stable > soon. glibc-2.13-r4 is already stable on most arches, anything else to do here? Closing |