[Python-Dev] PyGEGL instant crash (Python regression?)
Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org), with SVN Python? When I 'import gegl', that causes an immediate crash with the following backtrace. babl-db.c:100 babl_db_insert() Ek Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1210014016 (LWP 30914)] 0xe410 in __kernel_vsyscall () #0 0xe410 in __kernel_vsyscall () #1 0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb6e93df4 in babl_backtrack () at babl-internal.c:68 #5 0xb6e93e15 in babl_die () at babl-internal.c:74 #6 0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100 #7 0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135 #8 0xb6ef7dea in init () at CIE-Lab.c:427 #9 0xb7b191b3 in babl_extension_init () at babl-extension.c:194 #10 0xb7b16a2f in babl_init () at babl.c:40 #11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0, data=0x0, error=0x0) at gegl-init.c:199 #12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at gegl-init.c:73 #13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139 #14 0xb7f82f21 in initgegl () at geglmodule.c:57 #15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 "gegl", pathname=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", fp=0xfe00) at ./Python/importdl.c:53 #16 0x080d5327 in load_module (name=0xbffa2177 "gegl", fp=0x0, buf=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", type=3, loader=0xbffa0974) at Python/import.c:1752 #17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 "gegl", fullname=0xbffa2177 "gegl") at Python/import.c:2394 #18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0, p_name=, buf=0xbffa2177 "gegl", p_buflen=0xbffa3178) at Python/import.c:2214 #19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc, locals=, fromlist=0x81343c0, level=-1) at Python/import.c:1995 #20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl", globals=0xb7de2acc, locals=0xb7de2acc, fromlist=0xfe00, level=-512) at Python/import.c:2066 #21 0x080b5658 in builtin___import__ (self=0x0, args=0xfe00, kwds=0xfe00)c:1995 at Python/bltinmodule.c:47 #22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfe00, kw=0xfe00) at Objects/abstract.c:1860 #23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfe00, arg=0xb7ddecac, kw=0x0) at Python/ceval.c:3433 #24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at Python/ceval.c:2071 #25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968, globals=0xb7de2acc, locals=0xb7de2acc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2840 #26 0x080c14c6 in PyEval_EvalCode (co=0xfe00, globals=0xfe00, locals=0xfe00) at Python/ceval.c:493 #27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfe00, filename=0x8116d6e "", flags=0xbffa3688) at Python/pythonrun.c:1293 #28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240, filename=0x8116d6e "", flags=0xbffa3688) at Python/pythonrun.c:723 #29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240, filename=0x8116d6e "", closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692 #30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527 #31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119 I'm pretty sure that the bug lies in either Python or the pygegl module, as I've ran the babl and gegl tests successfully (and the gegl editor works okay too) (btw, this is with both SVN python and SVN gegl -- PyGEGL is included in the gegl repository; in order to test this, you might also need the SVN version of babl. Lastly, in the gegl tree, you can find PyGEGL source in the bindings/pygegl/ dir.) I posted this report originally to the gegl-developer list. Kevin Cozens, the PyGEGL maintainer, said: > I have only tested pyGEGL with the 2.4 version of Python. It possible (or very > likely?) that something has changed in the 2.6 version of Python. I don't have > the 2.6 version installed at the moment so I can't investigate this further. Sven Neumann said: > Have you contacted the python developers then? This looks a lot like a > regression in Python and I guess they would like to hear about it before > the release the next version. Hence I'm posting it here. Perhaps someone can shed some light on what is happening here? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyGEGL instant crash (Python regression?)
"David Gowers" <[EMAIL PROTECTED]> wrote: > Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org), > with SVN Python? > When I 'import gegl', that causes an immediate crash with the > following backtrace. I would wager a beer or two that the issue is in the wrapping of gegl. Having recently started wrapping modules by hand and with Swig, I have come to notice that making a mistake with refcounts can lead to segfaults like you are seeing. If you are getting that immediately upon import, you may want to check to make sure that the function that is initializing your module (typically something like init_gegl) is doing the right things (I can't really offer any suggestions on what to check for, I literally only started wrapping stuff by hand yesterday; previously I used Pyrex, which can handle all refcounts for you if desired). - Josiah > > > babl-db.c:100 babl_db_insert() >Ek > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > [Thread debugging using libthread_db enabled] > [New Thread -1210014016 (LWP 30914)] > 0xe410 in __kernel_vsyscall () > #0 0xe410 in __kernel_vsyscall () > #1 0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb6e93df4 in babl_backtrack () at babl-internal.c:68 > #5 0xb6e93e15 in babl_die () at babl-internal.c:74 > #6 0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100 > #7 0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135 > #8 0xb6ef7dea in init () at CIE-Lab.c:427 > #9 0xb7b191b3 in babl_extension_init () at babl-extension.c:194 > #10 0xb7b16a2f in babl_init () at babl.c:40 > #11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0, > data=0x0, error=0x0) >at gegl-init.c:199 > #12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at > gegl-init.c:73 > #13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139 > #14 0xb7f82f21 in initgegl () at geglmodule.c:57 > #15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 "gegl", >pathname=0xbffa1103 > "/usr/lib/python2.6/site-packages/geglmodule.so", fp=0xfe00) >at ./Python/importdl.c:53 > #16 0x080d5327 in load_module (name=0xbffa2177 "gegl", fp=0x0, >buf=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", type=3, >loader=0xbffa0974) at Python/import.c:1752 > #17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 "gegl", >fullname=0xbffa2177 "gegl") at Python/import.c:2394 > #18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0, > p_name=, >buf=0xbffa2177 "gegl", p_buflen=0xbffa3178) at Python/import.c:2214 > #19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc, >locals=, fromlist=0x81343c0, level=-1) at > Python/import.c:1995 > #20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl", > globals=0xb7de2acc, >locals=0xb7de2acc, fromlist=0xfe00, level=-512) at Python/import.c:2066 > #21 0x080b5658 in builtin___import__ (self=0x0, args=0xfe00, > kwds=0xfe00)c:1995 >at Python/bltinmodule.c:47 > #22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfe00, > kw=0xfe00) >at Objects/abstract.c:1860 > #23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfe00, > arg=0xb7ddecac, kw=0x0) >at Python/ceval.c:3433 > #24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at > Python/ceval.c:2071 > #25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968, > globals=0xb7de2acc, locals=0xb7de2acc, >args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, > closure=0x0) >at Python/ceval.c:2840 > #26 0x080c14c6 in PyEval_EvalCode (co=0xfe00, globals=0xfe00, > locals=0xfe00) >at Python/ceval.c:493 > #27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfe00, > filename=0x8116d6e "", >flags=0xbffa3688) at Python/pythonrun.c:1293 > #28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240, > filename=0x8116d6e "", >flags=0xbffa3688) at Python/pythonrun.c:723 > #29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240, > filename=0x8116d6e "", >closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692 > #30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527 > #31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 > #32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119 > > > I'm pretty sure that the bug lies in either Python or the pygegl module, as > I've > ran the babl and gegl tests successfully (and the gegl editor > works okay too) > > (btw, this is with both SVN python and SVN gegl -- PyGEGL is included > in the gegl repository; in order to test this, you might also need the > SVN version of babl. Lastly, in the gegl tree, you can find PyGEGL > source in the bindings/pygegl/ dir.) > > I posted this report originally to
Re: [Python-Dev] PyGEGL instant crash (Python regression?)
On 7/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "David Gowers" <[EMAIL PROTECTED]> wrote: > > Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org), > > with SVN Python? > > When I 'import gegl', that causes an immediate crash with the > > following backtrace. > > I would wager a beer or two that the issue is in the wrapping of gegl. > Having recently started wrapping modules by hand and with Swig, I have > come to notice that making a mistake with refcounts can lead to > segfaults like you are seeing. If you are getting that immediately upon > import, you may want to check to make sure that the function that is > initializing your module (typically something like init_gegl) is doing > the right things (I can't really offer any suggestions on what to check > for, I literally only started wrapping stuff by hand yesterday; > previously I used Pyrex, which can handle all refcounts for you if > desired). > Well, okay; but how does that account for the fact that Kevin reports it works under 2.4, but it doesn't work under 2.6? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyGEGL instant crash (Python regression?)
David Gowers wrote: > Well, okay; but how does that account for the fact that Kevin reports > it works under 2.4, but it doesn't work under 2.6? The most likely culprit is that some of the code is using PyMem_Free on a pointer allocated with PyObject_Malloc (or vice-versa). This has always been illegal, but prior to 2.5 the Python memory allocator tied itself in knots to try to avoid crashing when client code broke the rules. The changes in 2.5 to release unused memory back to the OS required that those knots be cut. The what's new document for each release is a good resource for these kinds of problems, especially its porting section: http://docs.python.org/whatsnew/porting.html Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] uuid creation not thread-safe?
I discovered what appears to be a thread-unsafety in uuid.py. This is in the trunk as well as in 3.x; I'm using the trunk here for easy reference. There's some code around like 395: import ctypes, ctypes.util _buffer = ctypes.create_string_buffer(16) This creates a *global* buffer which is used as the output parameter to later calls to _uuid_generate_random() and _uuid_generate_time(). For example, around line 481, in uuid1(): _uuid_generate_time(_buffer) return UUID(bytes=_buffer.raw) Clearly if two threads do this simultaneously they are overwriting _buffer in unpredictable order. There are a few other occurrences of this too. I find it somewhat disturbing that what seems a fairly innocent function that doesn't *appear* to have global state is nevertheless not thread-safe. Would it be wise to fix this, e.g. by allocating a fresh output buffer inside uuid1() and other callers? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Need help fixing tests in str/unicode branch
Thanks to all who helped fixing tests in the str/unicode branch! We're down to about 35 failing tests. I still need help -- especially since we're now getting into territory that I don't know all that well, for example the email package or XML support. The list of unit tests that need help is still on the wiki: http://wiki.python.org/moin/Py3kStrUniTests Instructions on how to help and how to avoid duplicate work are also there. Please help! Thanks to all those who already fixed one or more tests! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
