Hi, Now having gone deeper into the matter i found out a bug, and can further get into details about when a segfault still occurs. The relevant fact i did not mention last time is that i'm running shapely on a 64 bit CPU.
1) http://trac.gispython.org/lab/browser/Shapely/tags/rel-1.0.13/shapely/geometry/base.py ay line 352 you use size = c_int() and later on pass it as size size arg to GEOS' GEOSGeomToWKB_buf. This is wrong on 64 bit processors. Please use size = c_size_t() (8 byte long on 64 bit) 2) I could find what may be a corelated symptom, and easily to check: the __geom__ type is int. This causes segfaults when the actual ponter type has a value >2^32-1. I could not follow the code to the point where __geom__ is set, but am searching for it. Perhaps you can give me a hint ? 2009/10/5 Sean Gillies <[email protected]>: > On Oct 3, 2009, at 7:52 PM, Paul Balomiri wrote: > >> Hi, >> >> I encountered a similar problem to >> http://lists.osgeo.org/pipermail/geos-devel/2009-July/004280.html , >> which is >> at the exact same execution point. >> >> I am using shapely 1.0.13. As the lib is linked with PyDLL into >> python, the GIL (Global Interpreter Log) is used to schedule library >> entrance ( = no python code (in any thread) runs concurrently), >> so my first guess was, that an init error or an error in handling the >> global Context might cause the segfault. >> >> The backtrace I got from gdb is >> >> >> [Switching to Thread 0x7fffe7f076f0 (LWP 6598)] >> geos::io::WKBWriter::write (this=0x7fffeff120c0, g...@0xd8005270, >> o...@0x7fffeff11f50) at WKBWriter.cpp:77 >> 77 switch (g.getGeometryTypeId()) { >> Current language: auto; currently c++ >> (gdb) where >> #0 geos::io::WKBWriter::write (this=0x7fffeff120c0, g...@0xd8005270, >> o...@0x7fffeff11f50) at WKBWriter.cpp:77 >> #1 0x00007fffe6883549 in GEOSGeomToWKB_buf_r (extHandle=0xa5beb0, >> g=0xd8005270, size=0x14407f0) at geos_ts_c.cpp:948 >> #2 0x00007fffe6aa53b8 in ffi_call_unix64 () at >> /build/buildd/python2.6-2.6.2/Modules/_ctypes/libffi/src/x86/ >> unix64.S:75 >> Python stacktrace: >> >> [Python Stack] >> >> #46 0x0000000000417ae9 in _start () at ../sysdeps/x86_64/elf/start.S: >> 113 >> >> A full stacktrace is included as an attachment. I have augmented the >> stacktrace with the python >> stackframe where the stack frame is in python code. >> >> I was wondering why GEOSGeomToWKB_buf is called, but >> GEOSGeomToWKB_buf_r appears on the stacktrace. >> >> I do use threads in the application, but only the main thread has >> calling points to shapely. >> Also the application uses SQLAlchemy with the user defined Geometry >> type from shapely. The gluecode is part of mapfish. >> >> Perhaps you have some ideas about why the segfault shows up. I'm not >> familiar with the way >> shapely handles GEOS c pointers. In gdb the geos geometry object >> g...@0xd8005270 points to an adress >> >> trying to access the geometry object reveals >> >> (gdb) p g >> $1 = (const geos::geom::Geometry &) @0xd8005270: <error reading >> variable> >> >> >> regards, >> Paul > > Hi Paul, > > I'm sorry you're experiencing trouble with Shapely. If you can write a > Python program that doesn't depend on MapFish or SQLAlchemy or PostGIS > (I don't have that stack running right now) that reliably crashes, > I'll get right on it. Maybe it's just a matter of writing out WKB from > multiple threads at once. > > If you're using GEOS 3.1, the non-reentrant API is just a thin layer > over the reentrant one, so EOSGeomToWKB_buf_r will always be called. > > Cheers, > > -- > Sean > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community > -- [email protected] _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
