[GRASS-dev] [GRASS GIS] #1841: segmentation fault in v.patch

GRASS GIS GRASS GIS developer
1

#1841: segmentation fault in v.patch
----------------------+-----------------------------------------------------
Reporter: pertusus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: | Platform: Linux
      Cpu: x86-64 |
----------------------+-----------------------------------------------------
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}
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1841&gt;
GRASS GIS <http://grass.osgeo.org>

2

#1841: segmentation fault in v.patch
----------------------+-----------------------------------------------------
Reporter: pertusus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: | Platform: Linux
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by mmetz):

Replying to [ticket:1841 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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1841#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#1841: segmentation fault in v.patch
-----------------------+----------------------------------------------------
  Reporter: pertusus | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Resolution: invalid | Keywords:
  Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Changes (by pertusus):

  * status: new => closed
  * resolution: => invalid

Comment:

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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1841#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>