Opened 2 years ago

Closed 2 years ago

#3245 closed defect (fixed)

inconsistent ownerhips rules from liblwgeom mediated GEOS constructive functions

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 2.1.9
Component: postgis Version: 2.0.x
Keywords: Cc:

Description

The functions lwgeom_clip_by_rect, lwgeom_difference, lwgeom_symdifference, lwgeom_intersection, lwgeom_unaryunion, lwgeom_linemerge (and maybe others) contain short-circuits that simply return a clone of one of the arguments, but the clone is not deep so that the caller doesn't know if the arguments can be freely released w/out destroying the return.

For consistency reasons it'd be good to always give the caller a fully owned object.

I think this problem goes back as long as 2.0, but not sure if it is worth fixing that much in the past.

Change History (4)

comment:1 Changed 2 years ago by strk

Owner: changed from pramsey to strk
Status: newassigned

comment:2 Changed 2 years ago by strk

lwgeom_split is also affected

comment:3 Changed 2 years ago by strk

r13942 fixes this problem in trunk (2.2.0). Alessandro: is spatialite use of liblwgeom from PostGIS 2.0 and 2.1 possibly affected by this issue ? You should be able to test by using any of the aforementioned functions with an EMPTY argument and checking memory for errors or leaks (there would be no error nor leak if you release the non-empty argument _after_ using the return object).

comment:4 Changed 2 years ago by strk

Milestone: PostGIS 2.2.0PostGIS 2.1.9
Resolution: fixed
Status: assignedclosed

Well, I decided to backport this to 2.1 branch, with r13944 (2.1.9) -- won't do 2.0

Note: See TracTickets for help on using tickets.