[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