[postgis-devel] WKB Problems on 64-Bit Linux

[TECHER Jean David]

Hi

I have the same problem as U on a AMD 64 debian sarge with PG 8.0.0 postgis
cvs

Sandro have U any idea about to resolve it???
----------------------------------------------------------------
TECHER Jean David
Responsable Informatique 01MAP
e-mail: davidtecher at yahoo.fr
Bureau: 04 67 45 60 27
Portable: 06 85 37 36 75
site perso : http://techer.pascal.free.fr/postgis/
site pro: http://www.01map.com/download/
K-S:"The greatest trick the devil pulled off was convincing people he didn't
exist"
------------------------------------------------------------
----- Original Message -----
From: "Markus Schaber" <markus at schabi.de>
To: "PostGIS Development Discussion" <postgis-devel at postgis.refractions.net>
Sent: Tuesday, March 08, 2005 6:13 PM
Subject: [postgis-devel] WKB Problems on 64-Bit Linux


> Hi,
>
> I just ran an extended variant[1] of jdbc2 "make alltests" against the
> 64-bit PostGIS enabled server. As it fails on 244 tests that all pass on
> IA32, there seems to be a rather serious WKB parsing problem on 64-Bit.
>
> I identified some of the failed queries from the test log, and here they
> are:
>
> jdbc_test=# select
>
'010400000002000000010100000000000000000026400000000000002840010100000000000
000000034400000000000003440'::geometry;
> ERROR:  invalid wkb
> jdbc_test=# select
>
'0104000080020000000101000080000000000000264000000000000028400000000000002A4
00101000080000000000000344000000000000034400000000000003440'::geometry;
> ERROR:  invalid wkb
>
> jdbc_test=# select
>
'01030000C002000000050000000000000000002440000000000000244000000000000000000
000000000001C400000000000003440000000000000244000000000000000000000000000001
C400000000000003440000000000000344000000000000000000000000000001C40000000000
0003440000000000000244000000000000000000000000000001C40000000000000244000000
0000000244000000000000000000000000000001C40050000000000000000001440000000000
000144000000000000000000000000000001C400000000000001440000000000000184000000
000000000000000000000001C400000000000001840000000000000184000000000000000000
000000000001C400000000000001840000000000000144000000000000000000000000000001
C400000000000001440000000000000144000000000000000000000000000001C40'::geomet
ry;
> ERROR:  invalid wkb
> jdbc_test=# select
>
'00C000000300000002000000054024000000000000402400000000000000000000000000004
01C000000000000403400000000000040240000000000000000000000000000401C000000000
000403400000000000040340000000000000000000000000000401C000000000000403400000
000000040240000000000000000000000000000401C000000000000402400000000000040240
000000000000000000000000000401C000000000000000000054014000000000000401400000
00000000000000000000000401C0000000000004014000000000000401800000000000000000
00000000000401C0000000000004018000000000000401800000000000000000000000000004
01C000000000000401800000000000040140000000000000000000000000000401C000000000
000401400000000000040140000000000000000000000000000401C000000000000'::geomet
ry;
>
> ERROR:  invalid wkb
>
> jdbc_test=# select
>
'010300000002000000050000000000000000002440000000000000244000000000000034400
0000000000024400000000000003440000000000000344000000000000034400000000000002
4400000000000002440000000000000244005000000000000000000144000000000000014400
0000000000014400000000000001840000000000000184000000000000018400000000000001
840000000000000144000000000000014400000000000001440'::geometry;
> ERROR:  invalid wkb
> jdbc_test=# select
>
'000000000300000002000000054024000000000000402400000000000040340000000000004
0240000000000004034000000000000403400000000000040340000000000004024000000000
0004024000000000000402400000000000000000005401400000000000040140000000000004
0140000000000004018000000000000401800000000000040180000000000004018000000000
000401400000000000040140000000000004014000000000000'::geometry;
>
> It seems that it can parse more bytea reps than hexed reps, and it also
> seems that it fails on XDR more often than on NDR.
>
> The last two hexEWKB reps above both represent 'POLYGON((10 10,20 10,20
> 20,20 10,10 10),(5 5,5 6,6 6,6 5,5 5))', it seems to be very critical
> case as it is failing on both binary and hex encoding, as well as on
> both XDR and NDR encoding. You can also provoke it via:
>
> jdbc_test=# select 'POLYGON((10 10,20 10,20 20,20 10,10 10),(5 5,5 6,6
> 6,6 5,5 5))'::geometry::bytea::geometry;
> ERROR:  invalid wkb
> jdbc_test=# select 'POLYGON((10 10,20 10,20 20,20 10,10 10),(5 5,5 6,6
> 6,6 5,5 5))'::geometry::text::geometry;
> ERROR:  invalid wkb
>
> For the curious, I also attached the full test.log file in bzip2
> compressed format.
>
> HTH,
> Markus
>
> Footnotes:
> [1] The extensions include EWKB and hexEWKB input, for which I added
> support. I did not commit this code yet, as I think it is 1.1 material.
> The 1.0.0 code does not utilize WKB parsing on the server side, and so
> fails all tests.
>
> --
> Markus Schaber - http://schabi.de/
>
> But hey!, Standard compliance is something we should strive for, so
> let's try and change the Standard :-) [Alexandre Oliva, GCC Developer]
>


----------------------------------------------------------------------------
----


> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>