segmentation fault in v.patch

[pertusus]

A very simple v.patch segfaults. I tried to poke around in the code, and I found some leads, but I cannot really dig further. It is somewhat strange that nobody else stumbled on it.

I attach a tarball to reproduce. Simply unpack, edit bug_v_patch.sh if you want to change the paths to grass, then run bug_v_patch.sh:

.....
Writing attributes...
./bug_v_patch.sh: line 35: 32630 Segmentation fault      v.patch -e -a input=test_bug_v_patch_one output=test_bug_v_patch_two --o

I produced a backtrace from within the grass shell

> gdb --args v.patch -e -a input=test_bug_v_patch_one output=test_bug_v_patch_two --o
(gdb) run
....
Program received signal SIGSEGV, Segmentation fault.
__strcpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy.S:177
177             movdqa  %xmm1, (%rdi)      /* store first 16 bytes into rdi */
(gdb) bt
#0  __strcpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy.S:177
#1  0x00007ffff79882de in set_string (x=0x7fffffffdd50, s=<value optimized out>, copy=<value optimized out>)
    at string.c:101
#2  0x0000000000402d08 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:285
(gdb) 

trying to look at what happens

(gdb) break main.c:285
Breakpoint 1 at 0x402cf7: file main.c, line 285.
(gdb) run
Breakpoint 1, main (argc=<value optimized out>, argv=<value optimized out>) at main.c:285
285             db_set_string(&table_name_out, fi_out->table);
(gdb) print table_name_out
$1 = {string = 0x0, nalloc = 21}
(gdb) 

The string pointer maybe should not be NULL.

Looking at what point it becomes null, by poking in gdb, I found that in fact the string is filled correctly at l 139, and if I set a breakpoint I can see its value. I set a new breakpoint at line 154, I can see that the string is set to null at that point (I also have a breakpoint l 156):

(gdb) break main.c:154
Breakpoint 4 at 0x4029f9: file main.c, line 154.
(gdb) run
Breakpoint 4, main (argc=<value optimized out>, argv=<value optimized out>) at main.c:154
154                 Vect_open_old_head(&InMap, in_name, "");
(gdb) print table_name_out
$3 = {string = 0x800ed0 "test_bug_v_patch_two", nalloc = 21}
(gdb) n               
Breakpoint 2, main (argc=<value optimized out>, argv=<value optimized out>) at main.c:156
156                 fi_in = Vect_get_field(&InMap, 1);
(gdb) print table_name_out
$4 = {string = 0x0, nalloc = 21}

[pertusus]

tarball to reproduce the issue

[mmetz]

Replying to pertusus:

A very simple v.patch segfaults. I tried to poke around in the code, and I found some leads, but I cannot really dig further. It is somewhat strange that nobody else stumbled on it.

I attach a tarball to reproduce.

I can not reproduce the segfault. I followed your gdb debug procedure and did not get the db_string reset to NULL, it keeps the string that was set previously. Are you sure you are using the latest svn version and that you don't have local changes in v.patch or lib/db/dbmi_base/string.c?

Markus M

[pertusus]

I made no change in the code. However, after I did a make clean, a build and a reinstalled and it does not segfault anymore. So it does not look like an issue in grass code, sorry for the noise.

I have no precise idea on what could have caused that. One hypothesis may be prelink with randomized addresses, but that seems unlikely as both the executable and the libraries are in places where prelink should not venture according to what I understand about prelink configuration.

Another possibility could be that a partial build of the grass libraries is not enough to get things right, you have to relink all the executables that depend on the libraries and it is not done automatically? I just checked that executables are not relinked when a library dependency is rebuilt, but I am not very convinced that this explains anything. This goes against all I know about binary compatibility.