[GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

GRASS GIS trac at osgeo.org
Mon Jun 20 13:50:24 PDT 2016


#3062: Segmentation fault with r.buffer
-----------------------+-------------------------
  Reporter:  escheper  |      Owner:  grass-dev@…
      Type:  defect    |     Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster    |    Version:  7.0.4
Resolution:            |   Keywords:  r.buffer
       CPU:  Other     |   Platform:  Linux
-----------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:6 neteler]:
 > {{{
 > CMD='r.buffer input=r120749038 output=rasbuf distances=10.0
 units=kilometers --o'
 > valgrind --tool=memcheck --leak-check=yes --show-reachable=yes  $CMD --o
 > ==11148== Memcheck, a memory error detector
 >
 > ==11148==
 > ==11148== 933,120,000 bytes in 1 blocks are still reachable in loss
 record 73 of 73
 > ==11148==    at 0x4C2AB80: malloc (in /usr/lib/valgrind
 /vgpreload_memcheck-amd64-linux.so)
 > ==11148==    by 0x5076A4A: G__malloc (alloc.c:39)
 > ==11148==    by 0x40333B: read_input_map (read_map.c:39)
 > ==11148==    by 0x402814: main (main.c:141)
 > ...
 > }}}

 A segfault is reflected in valgrind as "invalid read of size ..." or
 "invalid write of size ...". Still reachable blocks are not a cause for
 segfault.

 Replying to [comment:11 escheper]:
 >
 > [...] I found the solution.
 >
 > Changing the MAPTYPE didn't solve the problem. But the problem was
 another overflow.
 >
 > I'm using a 64,800 x 129,600 grid which results in 8,398,080,000 cells
 (or bytes). This is far beyond the maxint (2,147,483,647) and causes the
 overflow.
 >
 > After changing most int variables in the r.buffer code in long types the
 segmentation fault disappeared :).
 >
 > I didn't check the output visually, that's what I need to do next.
 Having no segmentation fault is very promising.

 Note that long is a signed 32 bit integer except for POSIX 64 bit systems.
 On Windows, long is always 32 bit and would not solve the problem. Better
 use long long, or even better, ask for a platform-independent 64 bit
 integer type in GRASS.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3062#comment:13>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list