v.buffer: segfault in LL

[neteler]

Inspired by an article [1] I tried v.buffer in a EPSG 4326 location:

GRASS 7.7.svn (latlong_wgs84):~ >
g.region n=90 s=-90 w=-180 e=180 res=1

v.random output=random100 n=100

v.buffer input=random100 output=random100_buff distance=0:00:01
Note: In latitude-longitude coordinate system specify distances in degree
unit
Buffering features...
Segmentation fault (core dumped)

Minimal debugging:

gdb v.buffer
GNU gdb (GDB) Fedora 8.2-6.fc29
(gdb) r input=random100 output=random100_buff distance=0:00:01 --o
...
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f71bc4 in Vect_point_buffer2 () from /home/mneteler/software/grass77/dist.x86_64-pc-linux-gnu/lib/libgrass_vector.7.7.so

Version:

g.version -g
version=7.7.svn
date=2019
revision=r74334M
build_date=2019-04-02
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8

In G76 it also crashes.

[1] ​https://spatialthoughts.com/2019/04/05/geodesic-buffers-in-qgis/

[mmetz]

Replying to neteler:

Inspired by an article [1] I tried v.buffer in a EPSG 4326 location:

GRASS 7.7.svn (latlong_wgs84):~ >
g.region n=90 s=-90 w=-180 e=180 res=1

v.random output=random100 n=100

v.buffer input=random100 output=random100_buff distance=0:00:01
Note: In latitude-longitude coordinate system specify distances in degree
unit
Buffering features...
Segmentation fault (core dumped)

distance=0:00:01 becomes distance=0 because distance must be of type double, in this case 1/3600 = 0.0002777778

[mmetz]

In 74387:

v.buffer: +test for zero distance, see #3814

[mmetz]

In 74388:

v.buffer: +test for zero distance, see #3814 (backport trunk r74387)

[neteler]

Thanks, fixed!

Yes, the zero distance results from me having specified the distance in sexagesimal notation. g.region uses G_scan_northing() etc for that. But that's probably for a separate enhancement ticket.