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

[strk at refractions.net]

Even simpler. I get a segfault on this:

	SELECT 'POINT()'::geometry;

[ x86_64 GNU/Linux ]

--strk;

On Tue, Mar 08, 2005 at 06:18:01PM +0100, TECHER Jean David wrote:
> 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
> >
> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel