invalid memory alloc request size 4294967294

[vnhjdh]

After a clean installation of postgres 8.4 and 1.4.0 on windows xp I now get invalid memory alloc request size 4294967294 errors on selects like:

SELECT AsSvg (TransScale((ST_Intersection(way,GeomFromText('MULTIPOLYGON(((1396734 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734 7490559)))', 900913))), -1396736, -7491072, 1.0, 1.0), 0, 0) as GeomAsSvg, label_id_z0 FROM planet_osm_line WHERE (way && GeomFromText('MULTIPOLYGON(((1396734 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734 7490559)))', 900913)) and ((railway='rail' and not ((tunnel is not null and tunnel='yes') or (tunnel is not null and tunnel='true'))))

[robe]

Can you provide an isolated example of this. One that doesn't require a table.

for example I tried this

SELECT AsSvg
 (TransScale(GeomFromText('MULTIPOLYGON(((1396734
 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734
 7490559)))', 900913), -1396736, -7491072, 1.0, 1.0), 0, 0)

and that works fine under windows Vista 8.4, PostGIS 1.4

Alternatively you can attach a small dataset that exhibits the problem.

Thanks, Regina

[vnhjdh]

Replying to robe:

Can you provide an isolated example of this. One that doesn't require a table.

for example I tried this

SELECT AsSvg
 (TransScale(GeomFromText('MULTIPOLYGON(((1396734
 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734
 7490559)))', 900913), -1396736, -7491072, 1.0, 1.0), 0, 0)

and that works fine under windows Vista 8.4, PostGIS 1.4

Alternatively you can attach a small dataset that exhibits the problem.

Thanks, Regina

SELECT (TransScale((ST_Intersection(way,GeomFromText('MULTIPOLYGON(((1396734 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734 7490559)))', 900913))), -1396736, -7491072, 1.0, 1.0)) FROM planet_osm_line

returns geometry: "010700002031BF0D0000000000"

With AsSvg in the select

SELECT AsSvg(TransScale((ST_Intersection(way,GeomFromText('MULTIPOLYGON(((1396734 7490559, 1397249 7490559, 1397249 7491074, 1396734 7491074, 1396734 7490559)))', 900913))), -1396736, -7491072, 1.0, 1.0)) FROM planet_osm_line

returns: invalid memory alloc request size 4294967294

[pramsey]

We need an example we can run ourselves. Otherwise all we can say is "yes, that seems to be a bug". Try to create the smallest combination of data and SQL that will demonstrate the problem. In an ideal world you don't even need tables, you can recreate the bug with just SQL and data literals.

[robe]

Paul,

Actually he did.

This confirms the problem. running the below in PostgreSQL 8.4 windows vista, PostGIS 1.4

SELECT ST_AsSVG('010700002031BF0D0000000000');

I get a ERROR: invalid memory alloc request size 4294967294

the above resolves to an empty geometry collection. Haven't tested on my OpenSUSE boxes yet.

So I am accepting this as a bug.

[robe]

Get same error on my OpenSUSE box running 1.4 postgreSQL 8.2. Also happens on PostGIS 1.5 install. Does not happen on 1.3 so it appears the revamping of ST_AsSVG in 1.4 caused this. Reassigning to Olivier.

[vnhjdh]

Replying to robe:

Get same error on my OpenSUSE box running 1.4 postgreSQL 8.2. Also happens on PostGIS 1.5 install. Does not happen on 1.3 so it appears the revamping of ST_AsSVG in 1.4 caused this. Reassigning to Olivier.

There are more changes in the ST_AsSVG (1.4.0) functionality NOT documented anywhere (changelog or release note). It world be nice to know what is happening.

E.g. M 10 10 100 10 → M 10 10 L 100 10 (valid but change not documented and not as compact)!!!

[robe]

Sorry about that. I'll update the documentation accordingly. According to this commit (r3824) was changed to confirm to new BNF standards.

​http://www.w3.org/TR/SVG/paths.html#PathDataBNF

[robe]

Documentation corrected for PostGIS 1.5 at r4410 and PostGIS 1.4 at r4411

[pramsey]

Sorry, should have read more carefully. Fixed in 1.4 branch at r4414 and in trunk at r4415.

[mcayland]

Only a minor nit, but looking at the patch it doesn't seem particularly obvious what the new section of code is doing/trying to avoid - can we add a comment to this?

ATB,

Mark.

[pramsey]

Thy will be done, r4420