Hi Markus, cc: List, thanks for your reply. I've reproduced the segmentation fault using the roads dataset from the Spearfish dataset. I've split the roads into three separate vector layers, and then patched them together as follows:
v.extract input=roads output=roads_interstate where="label='interstate'" v.extract input=roads output=roads_primary where="label LIKE 'primary%'" v.extract input=roads output=roads_secondary where="label LIKE 'secondary%'" ##here I patch one set of vectors without -e v.patch input=roads_primary,roads_secondary out=roads_12 v.patch -e input=roads_12,roads_interstate output=roads_patch Segmentation fault As mentioned previously this was caused by an oversight on my side, but it might be useful to check if all inputs to v.patch have a (valid) database table attached as well as the correct set of columns, rather than returning the segmentation fault. Hope that helps. best regards, Daniel On 28/03/2021 22:07, Markus Neteler wrote: > Hi Daniel, > > On Thu, Mar 11, 2021 at 11:35 AM Daniel McInerney > <daniel.o.mciner...@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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
