Re: [GRASS-user] v.patch segmentation fault
Hi Daniel, On Thu, Mar 11, 2021 at 11:35 AM Daniel McInerney 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
Re: [GRASS-user] Building grass version grass-7.8.5
Thanks for all of the great pointers. Updating Python3 to version 3.9.2 made it possible for me to build GRASS finally. A couple of small issues now have me slightly puzzled: 1) when I ran "grass79", the GUI popped up just fine the first time. However, the GUI did not entirely fit the screen (I can't see the bottom of the GUI, where the "start GRASS" button is). I am running a Debian Linux virtual machine (via virtualbox). 2) for some reason, I am now getting a new error whereby the GUI no longer pops up: "wxnviz.py: No module named grass.lib.ogsf" followed by "No such file or directory: /usr/local/grass79/gui/wxpython/xml/menudata.xml". I checked and I do have the /usr/local/grass79/gui/wxpython/xml directory with lots of files but not that one. Any ideas greatly appreciated. (Note; when the GUI did work the first time, I used the GRASS download capability to obtain the North Carolina dataset, Can't wait to visualize the weather dataset contained therein.) Best regards, Steve On Sat, Mar 27, 2021 at 4:25 AM Moritz Lennert wrote: > Actually, the trailing comma after **kwargs is a feature introduced in > recent Python 3 versions. It was recently introduced into our code through > Black [1]. > > So, make sure you have Python 3.6+ installed on your system and that this > is the Python version called during compilation. > > Moritz > > [1] https://github.com/OSGeo/grass/pull/1382 > > Am 27. März 2021 11:07:02 MEZ schrieb Moritz Lennert < > mlenn...@club.worldonline.be>: > > > > > >Am 26. März 2021 23:13:18 MEZ schrieb Stephen Kirby >: > >>Thanks Veronica for that good information. I've made some progress by > >>ensuring I had the libs it needs ready (GDAL, etc.). Now it is giving > me a > >>Python error : > >> > >> File > > >>"/home/me/grass/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py", > >>line 305, > >>**options, > >>SyntaxError: invalid syntax > >> > >>I am not a Python user so this is throwing me. I assume I need to > install > >>a Python (Python3?) module, via "pip install ..." I suppose. Can someone > >>tell me which module can fix this? > >> > >>For reference, the whole Python block of code containing the offending > >>line, from core.py is: > >>def make_command( > >> prog, > >> flags="", > >> overwrite=False, > >> quiet=False, > >> verbose=False, > >> superquiet=False, > >> errors=None, > >> **options, > >>); > > > > > >AFAICT there should not be a comma after **options. This would explain > the syntax error. > > > >Moritz > >___ > >grass-user mailing list > >grass-user@lists.osgeo.org > >https://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.select incredibly slow
Hi Uwe,
Am 27. März 2021 14:58:01 MEZ schrieb Uwe Fischer :
>Hello list,
>
>I have trouble selecting line features using their location compared to a
>polygon layer using v.select. The line features I want to select from are
>parcel borders, and the polygon layer is made up of tubular-shaped buffers
>around municipal borders. I need to find the parcel borders which are inside
>this buffer.
>
>The command line in a Python script I use is:
>
>grass.run_command('v.select', ainput='temp5', atype='line', binput='buff',
>blayer=1, btype='area', output='grenz', operator='within', overwrite=True)
>
>The process starts, but it runs incredibly slow (> 15 min) and it brings not
>the desired result (but trash data). When I start it in the GRASS ui, it
>also works very very slow.
>
>I have only about 2000 parcel borders, so it cannot be a problem of too much
>features. Furthermore, the exact same selection task is processed in QGIS 3
>in a second with perfect results.
>
>I used v.build on both maps before v.select, but it does not help.
>
>I would like to perform it in GRASS because it is part of a bigger data
>preparation script which makes my work a lot easier. So I need to integrate
>it here rather than selecting in QGIS manually.
First of all: which version of GRASS GIS are you using ?
I filed a bug about this same issue a few years ago [1] and Markus Metz
reorganized the code at the time to speed things up. I don't remember which
version was the first to include the fixes (7.6 ?). However, even though it was
slow, results were ok which doesn't seem to be the case for you, so that is a
bit worrying.
Can you reproduce the same issue with the example given in that bug report ? If
not can you provide a reproducible example, including relevant data ? Ideally
as a GitHub issue ?
As a workaround you could try either the alternative provided in the bug
report, or you could try to reduce the number of line candidates first using
v.select operator=overlap and using operator=within only on those selected in
the first call.
Moritz
[1] https://trac.osgeo.org/grass/ticket/3361
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
