[postgis-devel] alignment issues

strk at refractions.net strk at refractions.net
Thu Feb 10 05:18:07 PST 2005


I'm afraid these crashing points are due to memory alignment issues.
I wonder how can other functions work.

The question is exposed by David Blasby here:
http://postgis.refractions.net/pipermail/postgis-users/2004-March/004205.html

Current implementation overlook the issue, so for sure we have a portability
problem. 

The question is you cannot portably interpret a stream of bytes however
you like, because a pointer-to-type cannot hold arbitrary values, but
mast fall on a grid of cell-size dependent on the type pointed to.

For example, a double (32bits) *must* be reachable on a memory
address for which address%32==0.

The problem is probably in the POINTARRAY. Each deserialized geometry
type holds a pointer to one or more POINTARRAY. POINTARRAY structure
holds a pointer to a list of points, as an unsigned char *.

So far nothing should go bad.

Now. I've defined a getPoint(POINTARRAY *, int N) function returning a
'char *' pointing the the Nth point in the array, this is intended to
be casted to either POINT2D, POINT3DZ, POINT3DM or POINT4D on the
caller side.

This cast is unsafe as it tries to use an arbitrary memory location as
the address of a POINT*, which is basically a set of doubles.

A possible solution is dropping this access method (getPoint) and
always use functions filling contents of a provided POINT*, or returning
an actual POINT* [ on-demand copy ].

Another solution is having deserialized geometries make a copy of 
serialized points to ensure proper alignment.

What do hackers think about this ?
Is anyone here on postgis-devel testing postgi on Solaris ?

--strk;





On Thu, Feb 10, 2005 at 11:45:49AM +0100, strk at refractions.net wrote:
> I've went through the code and made sure 'unsigned char' is used
> wherever 'octet' is actually meant. 
> 
> See if this fixes your problem.
> 
> For all users testing RC releases: please give current CVS a check.
> 
> --strk;
> 
> On Thu, Feb 10, 2005 at 10:28:03AM +0100, strk at refractions.net wrote:
> > On Wed, Feb 09, 2005 at 07:07:53PM -0800, Ionut Iordache wrote:
> > > Hello,
> > > 
> > > I found a more specific reason why my installation crashes:
> > > 
> > > Following is an excerpt from running gdb against the backend and
> > > breaking at a point close to where it crashes after executing " select
> > > X(geom) from gtest;":
> > > 
> > > ----------------------------------------------------------------------
> > > Breakpoint 2, LWGEOM_x_point (fcinfo=0xffbed600) at lwgeom_ogc.c:528
> > > 528             if ( point == NULL ) PG_RETURN_NULL();
> > > (gdb) print point
> > > $1 = (LWPOINT *) 0x37f188
> > > (gdb) print point->point
> > > $2 = (POINTARRAY *) 0x37f248
> > > (gdb) print point->point->dims
> > > $3 = 0 '\0'
> > > (gdb) print point->point->npoints
> > > $4 = 1
> > > (gdb) n
> > > 531             p = (POINT2D *)getPoint(point->point, 0);
> > > (gdb) print p
> > > Cannot access memory at address 0xfffffff0
> > > (gdb) n
> > > 533             PG_RETURN_FLOAT8(p->x);
> > > (gdb) n
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > LWGEOM_x_point (fcinfo=0xffbed600) at lwgeom_ogc.c:533
> > > 533             PG_RETURN_FLOAT8(p->x);
> > > (gdb) 
> > > ------------------------------------------------------------------
> > > 
> > > My understanding is that the POINTARRAY structure passed to the "getPoint"
> > > function is somehow invalid... One obvious thing that I noticed (and I
> > > might be way off track here, it's my first time reading through this
> > > code...) is that the dimension is always 0, where this is noted in
> > > the source files:
> > > 
> > > /size of point represeneted in the POINTARRAY
> > > // 16 for 2d, 24 for 3d, 32 for 4d
> > > int
> > > pointArray_ptsize(const POINTARRAY *pa)
> > > {
> > >         return sizeof(double)*TYPE_NDIMS(pa->dims);
> > > }
> > > 
> > > I also tested with LINESTRING and pointArray_ptsize will always return
> > > 0 here...
> > > 
> > 
> > POINTARRAY.dims is used as a bitfield for hasZ and hasM flags. 0==2d.
> > Can you print value of pa->serialized_pointlist ?
> > Return from getPoint should be an offset from there
> > (+16*pointN for a 2d ptarray, same address X)
> > --strk;
> > 
> > 
> > > 
> > > Any help is greatly appreciated!
> > > 
> > > 
> > > Tuesday, February 8, 2005, 2:40:23 PM, you wrote:
> > > 
> > > II> Hello,
> > > 
> > > II> I've been having problems for a while with Postgis on Solaris 8
> > > II> (sparc). I have tried various combinations of Postgresql 8.0.1, 7.4.6
> > > II> with Postgis versions 0.9.1 and up.
> > > II> The problem is that after the packages compile relatively without
> > > II> hassle, I can't use any postgis spatial function without crashing the
> > > II> database.
> > > II> For example, I create an empty database, add the lwpostgis.sql
> > > II> extension, create a spatial table with point geometry, insert one row
> > > II> into the table... up to this point everything is fine... when I run
> > > II> "select astext(geom) ..." the point shows up correctly, but when I
> > > II> execute "select X(geom) ..." the backend crashes:
> > > 
> > > 
> > > II> server closed the connection unexpectedly
> > > II>          This probably means the server terminated abnormally
> > > II>          before or while processing the request.
> > > II> The connection to the server was lost. Attempting reset: Failed
> > > 
> > > 
> > > II> I compiled with LDFLAGS="-lstdc++ -lgcc" and gcc  3.4.1.
> > > II> My gcc installation is configured as follows:
> > > II> Reading specs from
> > > II> /a/perry/data/pkgs3/local/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.1/specs
> > > II> Configured with: ../configure --with-as=/usr/ccs/bin/as
> > > II> --with-ld=/usr/ccs/bin/ld --disable-nls
> > > II> Thread model: posix
> > > II> gcc version 3.4.1
> > > 
> > > II> The compiler uses Sun's linker and I was wondering if this is part of
> > > II> the problem... When I try to compile with GNU's ld, I get a
> > > II> "option -dn and -P are incompatible" linker error.
> > > 
> > > II> The logs are not showing anything interesting, even with the highest
> > > II> debug option set...
> > > II> I also tried to debug the backend, but I get this error in gdb:
> > > II>   Reading symbols from /usr/local/lib/libstdc++.so.6...Error
> > > II> while reading shared library symbols:
> > > II>   Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
> > > 
> > > 
> > > 
> > > II> So, is anyone else using lwgeom Postgis on Solaris 8? Did you compile
> > > II> gcc from scratch, or used the binaries from sunfreeware.com ?
> > > II> Any ideas of what might go wrong with my installation?
> > > 
> > > 
> > > II> Many thanks,
> > > II> -----------------------------------------------
> > > II> Dorel Ionut Iordache - <ionut at eps.berkeley.edu>
> > > II> UC Berkeley - Earth & Planetary Science Dept.
> > > 
> > > II> _______________________________________________
> > > II> postgis-users mailing list
> > > II> postgis-users at postgis.refractions.net
> > > II> http://postgis.refractions.net/mailman/listinfo/postgis-users
> > > 
> > > 
> > > 
> > > -- 
> > > Best regards,
> > > -----------------------------------------------
> > > Dorel Ionut Iordache - <ionut at eps.berkeley.edu>
> > > UC Berkeley - Earth & Planetary Science Dept.
> > > 
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list