[GRASS-dev] Re: [GRASS GIS] #699: v.buffer2 segfault: in Vect_get_isle_points()

[GRASS GIS]

#699: v.buffer2 segfault:  in Vect_get_isle_points()
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev@…              
      Type:  defect   |      Status:  closed                   
  Priority:  normal   |   Milestone:  7.0.0                    
 Component:  Vector   |     Version:  6.4.0 RCs                
Resolution:  fixed    |    Keywords:  v.buffer                 
  Platform:  All      |         Cpu:  All                      
----------------------+-----------------------------------------------------

Comment(by mmetz):

 Replying to [comment:29 mlennert]:
 >
 [snip]
 > >
 > > It seems v.buffer2 has issues with the test cases described in the old
 RT bug 2765 whereas v.buffer does not...
 >
 > Just tested in dev6: I actually don't see any difference between
 v.buffer and v.buffer2 with the two test cases mentioned above. Both work
 fine.
 >
 So the segfault in G7 needs to be explained. BTW, works fine for me in G7.
 >
 > And I still support Markus in replacing v.buffer2 by v.buffer. I know
 this will be frustrating to see a SoC project apparently disappear, but
 IIUC, Markus has actually integrated some of the code into v.buffer, or ?
 >
 Yes, the solution for the buffer column bug has been adapted from
 v.buffer2 to v.buffer. And it is indeed frustrating to disable a GSoC
 project output. I started with v.buffer2, but I do not understand relevant
 parts of the code in buffer2.c, dgraph.[c|h], e_intersect.[c|h], all in
 lib/vector/Vlib/, so I went for the older v.buffer. Maybe someone else has
 more success.

 Anyway, the lesson learned is that GSoC needs more thorough quality
 control before broken modules end up in a stable release branch.

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/699#comment:30>
GRASS GIS <http://grass.osgeo.org>