[GRASS-user] v.patch segmentation fault

[Markus Neteler]

Hi Daniel,

On Thu, Mar 11, 2021 at 11:35 AM Daniel McInerney
<daniel.o.mcinerney at gmail.com> wrote:
>
> 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

Do you see a chance to provide a reproducible example?
Then we could run the debugger on it.
Certainly you may do that as well, with your data:

https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_GDB

It may give some insights why the segfault happens.

Best,
Markus