v.net.iso - Segmentation fault

[Bas Couwenberg]

As reported by Eduardo Corbelle Rico in ​Debian Bug #845429:

It happened to me that the use of v.net.iso command results in a segmentation fault. I could replicate the error in two different machines, with my own data and with both examples shown in the online manual ( https://grass.osgeo.org/grass70/manuals/v.net.iso.html ) using the Spearfish dataset for GRASS 7.

After consultation in the GRASS-user list, it seems that this is specific of the pre-compiled package (installed via apt-get), as the error does not appear when GRASS 7.0 is compiled from source in the same machine.

The related discussion on grass-user is at:

​https://lists.osgeo.org/pipermail/grass-user/2016-November/075606.html

Running the commands from the example gets the following backtrace from gdb:

(gdb) run
Starting program: /usr/lib/grass72/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=0x6427d0, item=item@entry=0x84cd30) at tavl.c:146
146     tavl.c: No such file or directory.
(gdb) bt
#0  tavl_probe (tree=tree@entry=0x6427d0, item=item@entry=0x84cd30) at tavl.c:146
#1  0x00007ffff6c55737 in dglTreeNodeAdd (pavl=0x6427d0, nKey=nKey@entry=1) at tree.c:73
#2  0x00007ffff6c4aa0c in dgl_add_edge_V1 (pgraph=0x7fffffffd3a8, nHead=<optimized out>, nTail=<optimized out>, nCost=1231014, nEdge=1, pvHeadAttr=pvHeadAttr@entry=0x0, pvTailAttr=0x0, pvEdgeAttr=0x0, nFlags=0) at edgemgmt-template.c:59
#3  0x00007ffff6c48a62 in dglAddEdge (pGraph=pGraph@entry=0x7fffffffd3a8, nHead=<optimized out>, nTail=<optimized out>, nCost=<optimized out>, nEdge=nEdge@entry=1) at graph.c:624
#4  0x00007ffff7ba1769 in Vect_net_build_graph (Map=Map@entry=0x7fffffffcfd0, ltype=ltype@entry=6, afield=afield@entry=1, nfield=nfield@entry=2, afcol=0x0, abcol=0x0, ncol=0x0, geo=0, version=1) at net_build.c:918
#5  0x0000000000402aee in main (argc=<optimized out>, argv=<optimized out>) at main.c:224

The issue can be reproduced with the GRASS 7.0.5 and 7.2.0-RC2 packages in Debian. In what way the custom compile differs from the Debian package build is not clear yet.

[mmetz]

Adding the full gdb backtrace for reference:

(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
        q = <optimized out>
        n = 0x55555599f7d0
        w = <optimized out>
        dir = <optimized out>
        da =
"\023\000\000\000\000\000\000\000\000\vb\367\377\177\000\000\300\266\23
1UUU\000\000\030\000\000\000\000\000\000"
        k = 0
        __PRETTY_FUNCTION__ = "tavl_probe"

The problem is that y = NULL. The test in tavl.c:139 should have been positive (new empty tree, the root must be set to the new node).

With regard to lib/vector/dglib, the source code of the Debian package seems to be identical to svn source code. Therefore, as long as manual compilation from source works, it seems that this is a packaging error. FWIW, I have updated tavl.c in trunk r69935 (newer version, more safety checks).

For debugging purposes, is there any way to reproduce compilation of the Debian package? It would be really nice to have a working Debian package. Increasing priority.

[Bas Couwenberg]

Replying to mmetz:

For debugging purposes, is there any way to reproduce compilation of the Debian package?

Yes, download the source package and build in a Debian unstable chroot with pdebuild. Or use the package git repository and the git-buildpackage workflow documented in the Debian GIS Policy:

​https://pkg-grass.alioth.debian.org/policy/packaging.html#git-packaging

Look at the debian/rules file for the configure options, and the build log or dpkg-buildflags for the build flags (CFLAGS, LDFLAGS, etc).

[mmetz]

Replying to sebastic:

Replying to mmetz:

For debugging purposes, is there any way to reproduce compilation of the Debian package?

Yes, download the source package and build in a Debian unstable chroot with pdebuild. Or use the package git repository and the git-buildpackage workflow documented in the Debian GIS Policy:

​https://pkg-grass.alioth.debian.org/policy/packaging.html#git-packaging

Look at the debian/rules file for the configure options, and the build log or dpkg-buildflags for the build flags (CFLAGS, LDFLAGS, etc).

Thanks. With Debian testing and GRASS 7.0.5, I could reproduce the segfault with the standard grass package, a rebuilt package, and also GRASS 7.0.5 compiled from source. Using the new tavl version from trunk solved the problem. Backported to G72 and G70 in r69951,2.

This code has been working fine for the last 14 years, therefore I am not sure if it is a bug in the code or a bug in Debian testing/unstable.

The ticket can be closed when new versions of G70 and G72 have been packaged for Debian and are confirmed working.

[Bas Couwenberg]

Confirmed fixed with the changes from r69951 which have been included as a patch in the Debian package.

[mmetz]

Replying to sebastic:

Confirmed fixed with the changes from r69951 which have been included as a patch in the Debian package.

Thanks a lot for patching, testing, and publishing the patched Debian packages for GRASS 7 so fast!

Maybe related:

There seems to be a problem with the interpretation of C language standards in Debian testing:

GRASS 7.0.5 does not compile with -std=c99 because math.h is not included (early error in lib/gis), even though math.h conforms to ISO C99 Standard: 7.12 Mathematics and is included if __USE_ISOC99 is defined.

GRASS 7.0.5 does compile with -std=gnu99 (C99 with GNU extensions).

[Bas Couwenberg]

Replying to mmetz:

GRASS 7.0.5 does not compile with -std=c99 because math.h is not included (early error in lib/gis), even though math.h conforms to ISO C99 Standard: 7.12 Mathematics and is included if __USE_ISOC99 is defined.

GRASS 7.0.5 does compile with -std=gnu99 (C99 with GNU extensions).

If GRASS should be compiled with -std=c99 or -std=gnu99 the configure script in GRASS should set these flags when appropriate.

[mmetz]

Replying to sebastic:

Confirmed fixed with the changes from r69951 which have been included as a patch in the Debian package.

For the record: the exact same segfault happens with Fedora 25 and with RHEL 7 + devtoolset-6. All use gcc-6.2.