On Wed, Nov 16, 2016 at 7:14 PM, Eduardo Corbelle Rico < [email protected]> wrote: > > O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu: > > > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico <eduardo.corb > > [email protected]> wrote: > > > > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > > > > <[email protected]> wrote: > > > > > > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > I am unable to use v.net.iso because of a "segmentation > > fault" > > > > > > > error. I > > > > > > > have a script that used to work correctly in GRASS 6.4 (32 > > > > > > > bit) > > > > > > > but > > > > > > > produces this error after I switched to GRASS 7.0.4 (64 > > bit). > > > > > > > > > > > > > > If I try to follow both examples shown in https://grass.osg > > eo.o > > > > > > > rg/g > > > > > > > rass > > > > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset for > > > > > > > GRASS 7) > > > > > > > the > > > > > > > same error appears: > > > > > > > > > > > > > > > Building graph... > > > > > > > > Registering arcs... > > > > > > > > Segmentation fault > > > > > > > > > > > > The segmentation fault must happen in the vector libraries. I > > > > > > tested > > > > > > on Linux and can not reproduce the segmentation fault. > > Valgrind > > > > > > also > > > > > > does not show anything that could cause a segmentation fault. > > Can > > > > > > you > > > > > > provide a gdb backtrace? > > > > > > > > > > > > Markus M > > > > > > > > > > Thank you Markus, > > > > > > > > > > My system is debian Stretch, and the following lines describe > > my > > > > > attempt at generating a gdb backtrace. Please let me know if I > > > > > should > > > > > do otherwise. > > > > > > > > So far so good. The module crashes in a library function that > > comes > > > > from libavl without modifications, but I can still not see why it > > > > could cause a segmentation fault. Can you recompile with the > > compiler > > > > debugging option -g? gdb will then be able to provide more > > > > information: > > > > > > > > make distclean > > > > CFLAGS="-g" ./configure <configure options> > > > > make > > > > > > > > optionally make install > > > > > > > > Then start GRASS and use gdb for v.net.iso as before. > > > > > > > > Markus M > > > > > > > > > > Dear Markus, > > > > > > Following those instructions does not seem to have changed the > > > resulting backtrace info (copied below). Maybe I missed something > > along > > > the way? > > > > > > --------------------- > > > > > > Is this something Debian specific that debugging symbols must be > > explicitly activated? Are you using GCC or another compiler? > > > > Alternatively, you can also try valgrind: > > > > CMD="v.net.iso input=myroads_net output=myroads_net_iso > > center_cats=1-100000 costs=1000,2000,5000 --o" > > valgrind --tool=memcheck --log-file=v.net.iso.vg.log $CMD > > > > Markus M > > > > You were right: it was my fault not having grass-core-dbgsym and grass- > dev-dbgsym packages installed.
You do not need these packages when you compile from source. > I copied below the results of the > debugging commands: > > ================ > GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso` > GNU gdb (Debian 7.11.1-2+b1) 7.11.1 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl > .html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/lib/grass70/bin/v.net.iso...Reading symbols > from /usr/lib/debug/.build- > id/5a/060fc6c3da41153d82601e3fa37ba6d88e9c6c.debug...done. > done. > > > (gdb) run input=myroads_net output=myroads_net_iso center_cats=1-100000 > costs=1000,2000,5000 This seems to be the GRASS version installed with your package manager because make install installs by default to /usr/local/: > Starting program: /usr/lib/grass70/bin/v.net.iso input=myroads_net > output=myroads_net_iso center_cats=1-100000 costs=1000,2000,5000 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux- > gnu/libthread_db.so.1". > Building graph... > Registering arcs... > > Program received signal SIGSEGV, Segmentation fault. > tavl_probe (tree=tree@entry=0x55555599b6c0, item=item@entry=0x55555599f > 7b0) > at tavl.c:146 > 146 tavl.c: Non hai tal ficheiro ou directorio. > (gdb) bt full > #0 tavl_probe (tree=tree@entry=0x55555599b6c0, item=item@entry=0x55555 > 599f7b0) > at tavl.c:146 > y = 0x0 > z = 0x55555599b6c0 > p = 0x0 At this stage (tavl.c:146), p should be equal to z, and p has been accessed previously, i.e. the segmentation fault should occur earlier. Therefore I suspect changes in tavl.c introduced when creating the package. You would need to remove all GRASS 7 packages from your system, then compile from source again. Markus M
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
