On Thursday 19 July 2007 19:28, Kevin Cozens wrote:

David Gowers wrote:

Using Python 2.6, typing 'import gegl' at the interpreter prompt causes the following crash to immediately happen:

[snip]

I'm also pretty sure that the bug lies in the pygegl module, as I've compiled and used many other modules for Python 2.6, with no problems, and I ran the babl and gegl tests successfully (and the gegl editor works okay too)

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.

Python 2.6???

The stable python is 2.5.1 - there is not even mention of a 2.6 release on teh python.org pages.

David: do you mean python 2.5 instead?

regards, js
->

On 7/20/07, Joao S. O. Bueno Calligaris wrote:

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.

Python 2.6???

The stable python is 2.5.1 - there is not even mention of a 2.6 release on teh python.org pages.

David: do you mean python 2.5 instead?

I mean python 2.6 -- that's SVN python's current version number. I believe a release is due fairly soon.

Hi,

On Fri, 2007-07-20 at 10:11 +0930, David Gowers wrote:

I mean python 2.6 -- that's SVN python's current version number. I believe a release is due fairly soon.

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.

Sven

On 20 Jul, David Gowers wrote:

I mean python 2.6 -- that's SVN python's current version number. I believe a release is due fairly soon.

Definitely not, not this year.

First, there will be some 3.0 alpha releases starting at the end of August(?).
Version 2.6 will come after 3.0 has stabilized since it's planned to be a release which aids in upgrading from 2.x to 3.0

Helmut.

BTW, Nick Coghlan said:

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

Which looks to me to be the most likely case, but I find the majority of the PyGEGL code inscrutable.

On 7/23/07, Kevin Cozens wrote:

David Gowers wrote:

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

The last two items on that page seem to be the more likely candidates that could cause problems. I don't see any calls to *_Malloc() or *_Free(). There are a number of calls to g_free(). If any of them are being called on items that were not allocated by a glib routine that could be the cause of the crash.

That page has also made me aware of at least one change needed for 64-bit machines.

--
Cheers!

Kevin.

Was trying to investigate this further. It turns out that current SVN of pygegl will not compile:

gegl.override: In function '_wrap_gegl_node_render': gegl.override:332: error: incompatible type for argument 2 of 'gegl_node_blit' gegl.override:332: error: incompatible type for argument 3 of 'gegl_node_blit' gegl.override:332: warning: passing argument 6 of 'gegl_node_blit' makes integer from pointer without a cast gegl.override: In function 'pygegl_register_classes': gegl.override:139: warning: dereferencing type-punned pointer will break strict-aliasing rules

due to a change in the blitting api.

Tiny patch is attached to fix it. The crash I originally reported still happens; none of the g_free calls seem to be freeing anything other than glib allocated memory.