[GRASS-user] v.patch segmentation fault

Daniel McInerney daniel.o.mcinerney at gmail.com
Thu Mar 11 02:35:53 PST 2021


Hi List,

I was running a series of steps in a workflow that patched different
line vector datasets together using v.patch, but at one stage I got a
Segmentation Fault without any indication of the cause. I soon realised
that one of the inputs that I had previously generated with v.patch, did
not have an attribute table as I had omitted the -e flag in error. Below
is the command that lead to the seg fault (including the gdb outputs),
where 'fishnet_1' did not have an attribute table.

Starting program: /usr/local/grass79/bin/v.patch -e
input=fishnet_1,fishnet_2 out=fishnet_all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecf09700 (LWP 18601)]
[New Thread 0x7fffec708700 (LWP 18602)]
[New Thread 0x7fffe9f07700 (LWP 18603)]
[New Thread 0x7fffe5706700 (LWP 18604)]
[New Thread 0x7fffe2f05700 (LWP 18605)]
[New Thread 0x7fffe0704700 (LWP 18606)]
[New Thread 0x7fffddf03700 (LWP 18607)]

Thread 1 "v.patch" received signal SIGSEGV, Segmentation fault.
db_get_table_number_of_columns (table=0x0) at table.c:140

140         return table->numColumns;

When I recreated 'fishnet_1' and included -e, and then re-ran the above
command, the process completed successfully. I'm therefore wondering if
it would be possible for v.patch  to check whether all of the inputs
have valid attribute tables/dblinks attached, in a similar way it checks
that all inputs have the same number of columns. I appreciate that I may
be overlooking a more fundamental reason why this can't be done, but
perhaps an error message could be included in lieu or in addition to the
segmentation fault. The above was tested on grass-gis 7.9 dev with both
sqlite and pg db drivers.

thanks in advance,

Daniel






More information about the grass-user mailing list