[postgis-devel] different EWKB representations on different machines?

[strk at refractions.net]

*WKB can either be big endian or little endian.
If you don't specify it it will be in the machine endian.

For POINT(1 1):

XDR:
\000\000\000\000\001?\360\000\000\000\000\000\000?\360\000\000\000\000\000\000

NDR:
\001\001\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?

1.0.0RC1 is known to contain memory alignment problems.
If you can reproduce bugs with 1.0.4 please come back on the issue.

--strk;

On Thu, Nov 10, 2005 at 12:59:35AM +0100, Alex Mayrhofer wrote:
> 
> All,
> 
> i'm currently investigating severe problems with PostGIS (postmaster 
> crashes, bus errors, etc) which only seem to occur on the sparc 
> architecture [i'm suspecting some alignment errors]. During tests, i found 
> out that the same geometry on three different machines/architectures, two 
> with PostGIS 1.0.0, one with 1.0.0RC1, yields three different EWKB formats.
> 
> Question: Shouldn't the EWKB representations be equal on all three machines?
> 
> details follow:
> ----
> box #1 (Debian sarge, PowerPC):
> 
> testdb=# select asewkb(geomfromewkt('SRID=-1;POINT(1 1)'));
>                                      asewkb
> --------------------------------------------------------------------------------
>  \377\001\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?
> (1 row)
> 
> testdb=# select version();
>                                                      version 
> 
> ------------------------------------------------------------------------------------------------------------------
>  PostgreSQL 7.4.7 on powerpc-unknown-linux-gnu, compiled by GCC 
> powerpc-linux-gcc (GCC) 3.3.5 (Debian 1:3.3.5-12)
> (1 row)
> 
> testdb=# select postgis_full_version();
>                                     postgis_full_version 
> 
> --------------------------------------------------------------------------------------------
>  POSTGIS="1.0.0RC1" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS DBPROC="0.1.0" 
> RELPROC="0.1.0"
> (1 row)
> 
> ------
> box #2 (intel i386, Debian sarge)
> 
> testdb=# select asewkb(geomfromewkt('SRID=-1;POINT(1 1)'));
>                                      asewkb
> --------------------------------------------------------------------------------
>  \001\001\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?
> (1 row)
> 
> testdb=# select version();
>                                           version 
> 
> -------------------------------------------------------------------------------------------
>  PostgreSQL 8.1.0 on i386-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5 
> (Debian 1:3.3.5-12)
> (1 row)
> 
> testdb=# select postgis_full_version();
>                                     postgis_full_version 
> 
> --------------------------------------------------------------------------------------------
>  POSTGIS="1.0.4" GEOS="2.1.3" PROJ="Rel. 4.4.9, 29 Oct 2004" DBPROC="0.3.0" 
> RELPROC="0.3.0"
> (1 row)
> 
> testdb=#
> 
> ----
> Box #3 (Ultrasparc, Debian sarge, userland in 32bit)
> 
> testdb=# select asewkb(geomfromewkt('SRID=-1;POINT(1 1)'));
>                                      asewkb
> --------------------------------------------------------------------------------
>  \000\000\000\000\001?\360\000\000\000\000\000\000?\360\000\000\000\000\000\000
> (1 row)
> 
> testdb=# select version();
>                                               version 
> 
> ----------------------------------------------------------------------------------------------------
>  PostgreSQL 8.1beta2 on sparc-unknown-linux-gnu, compiled by GCC cc (GCC) 
> 3.3.5 (Debian 1:3.3.5-13)
> (1 row)
> 
> testdb=# select postgis_full_version();
>                                     postgis_full_version 
> 
> --------------------------------------------------------------------------------------------
>  POSTGIS="1.0.4" GEOS="2.1.3" PROJ="Rel. 4.4.9, 29 Oct 2004" DBPROC="0.3.0" 
> RELPROC="0.3.0"
> (1 row)
> 
> 
> The "real problem" is that a great percentage of postgis related operations 
> on the Ultrasparc machine either yield weird error messages, or leads to a 
> bus error of the postmaster. I'm currently recompiling PostgreSQL with 
> --enable-cassert, but since Postgres regression went fine, i'd suspect the 
> problem to be somewhere  in the postgis code. More news as we get it.
> 
> any comments on this?
> 
> cheers
> 
> alex
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel