> "The same problem [segfault] could afflict any python package that > uses Ctypes on 64-bit systems without explicitly marking argument and > return types. " > > Looking back through the modwsgi thread and this one, everyone's on > 64bit, except the CentOS guy who said it worked ok on 32bit but not on > 64bit. > > Maybe thats the problem with the ctypes+geos bindings in GeoDjango? > I'm running something-pre-1.0, but I can try it on a trunk checkount > to confirm the same symptoms.
I realized the problems about not making explicit argument return types, and made _almost_ all of them explicit over a _year_ ago in r6653 (by adding the `prototypes` directory where all interactions with C functions were defined). Good to see that Shapely got around to eventually doing that, rather than the haphazard fixes they were implementing up to this point that never really addressed the underlying issues. The reason I said "almost" is that I purposely did not do this for routines that return strings allocated within GEOS. If you specified the response type as `c_char_p` then ctypes would convert to a Python object (str) when given to a ctypes error check function. In other words, because I was doing the proper thing and using the error check function it is not possible to set the response type to `c_char_p` _and_ get the pointer address to the string because all you got was a Python str instead. It's important to get the pointer address, otherwise I could not free the string memory allocated inside the GEOS library -- in other words, GeoDjango would leak memory every time one serialized to WKT if I didn't do it this way (that's bad). While it's not possible to get the pointer address when using `c_char_p` as the restype, I've since figured out that if you use a simple _subclass_ of `c_char_p` and use that for the response type I can get access to both the string value and the pointer address to be freed. I've implemented this patch in my minor refactor of the GEOS interface for 1.1 [1]. I've also created a ticket [2] and I'll attach a patch with the fix, which I'll commit to trunk and the 1.0.X branch within a week. And now I realized why I couldn't reproduce on CentOS -- I was using a 32-bit version; forgot to ask "what architecture", d'oh. -Justin [1] http://geodjango.org/hg/gis-geos [2] http://code.djangoproject.com/ticket/9747 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
