ST_AsTWKBAgg fails NULL crash test

[robe]

Just ran thru garden 2.2 pot of tests and got a crasher on twkb. This is running on:

POSTGIS="2.2.0dev r12313" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER PostgreSQL 9.3.3, compiled by Visual C++ build 1600, 64-bit

SELECT ST_AsTWKBAgg(foo1.the_geom, 3) As result FROM ((SELECT CAST(Null As geometry) As the_geom)) As foo1 LIMIT 3;

errors with:

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
psql:postgis_gardentest22.sql:272626: connection to server was lost

[nicklas]

Thanks for catching this!

Should be fixed in r12318

It now ignores null inputs and aggregates the other. That behavior can be questioned since that means the corresponding ID will be just lost.

The alternative I guess is putting some empty geometry in the aggregate, but I do not know if that is correct either. No big deal I guess.

[robe]

strk seems to have run into the issue again — strk comment on this one if you have confirmed you are running the latest and its still happening to you. Otherwise close.

[nicklas]

It doesn't crash for me now on 64 bit Debian. But as I commented 4 weeks ago I don't know if the behavior is the most correct.

If it still crashes for you strk, what system are you on?

[strk]

I don't see a testcase in r12318, could you please add one in regress/tickets.sql (and _expect) for this ?

SELECT '#2672', ST_AsTWKBAgg(null::geometry, 3)

I confirm it doesn't happen anymore (forgot to "make install" before running garden)

[nicklas]

Done in r12436

I close it.