[postgis-tickets] [PostGIS] #2307: ST_MakeValid outputs invalid geometries

[PostGIS]

#2307: ST_MakeValid outputs invalid geometries
-----------------------+----------------------------------------------------
  Reporter:  dmiranda  |       Owner:  strk         
      Type:  defect    |      Status:  new          
  Priority:  high      |   Milestone:  PostGIS 2.0.4
 Component:  postgis   |     Version:  2.0.x        
Resolution:            |    Keywords:  st_makevalid 
-----------------------+----------------------------------------------------
Changes (by strk):

  * owner:  pramsey => strk
  * status:  reopened => new


Comment:

 I found that there are already tests in cunit that expose the leak:
 {{{
 ==25260== HEAP SUMMARY:
 ==25260==     in use at exit: 504 bytes in 10 blocks
 ==25260==   total heap usage: 10,408 allocs, 10,398 frees, 397,158 bytes
 allocated
 ==25260==
 ==25260== 392 (40 direct, 352 indirect) bytes in 1 blocks are definitely
 lost in loss record 8 of 8
 ==25260==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 ==25260==    by 0x4E5044D: lwpoly_construct (lwpoly.c:52)
 ==25260==    by 0x4E775CD: lwgeom_make_valid (lwgeom_geos_clean.c:1049)
 ==25260==    by 0x40876F: test_lwgeom_make_valid (cu_clean.c:56)
 ==25260==    by 0x50952A9: ??? (in /usr/lib/libcunit.so.1.0.1)
 ==25260==    by 0x50956ED: ??? (in /usr/lib/libcunit.so.1.0.1)
 ==25260==    by 0x50958D7: CU_run_suite (in /usr/lib/libcunit.so.1.0.1)
 ==25260==    by 0x404ADE: main (cu_tester.c:197)
 }}}

 The leak goes away by re-introducing the lwgeom_free call. And no memory
 error is shown.
 But the test in regress fails...

 This bug is in search of a better fix. Will take a look.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2307#comment:11>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.