[GRASS-dev] [GRASS GIS] #2676: r.neighbors on large rasters

GRASS GIS trac at osgeo.org
Thu May 14 22:45:53 PDT 2015


#2676: r.neighbors  on large rasters
--------------------------+---------------------------------------
  Reporter:  dnewcomb     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  reopened
  Priority:  normal       |  Milestone:  7.0.1
 Component:  Default      |    Version:  svn-trunk
Resolution:               |   Keywords:  r.neighbors large rasters
       CPU:  x86-64       |   Platform:  Linux
--------------------------+---------------------------------------
Changes (by glynn):

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


Comment:

 Replying to [comment:2 dnewcomb]:

 > > What are the actual dimensions (rows x columns) of the current region?
 (The dimensions of the input map aren't directly relevant).

 Sorry, that's incorrect. If you don't use the -a flag, r.neighbors sets
 the region to match the input map.

 In any case, the cause is the use of G_alloca() for allocating temporary
 row buffers within the raster library. This is a macro which expands to
 alloca(), which allocates memory on the stack.

 While this is vastly more efficient than malloc() etc (alloca() may
 compile to just 2 CPU instructions), it doesn't report allocation failure;
 the next instruction to push something onto the stack will result in a
 segfault.

 1875705 columns at 8 bytes per cell corresponds to 15 MB for a row. On my
 system, the default maximum stack size (ulimit -s) is 8192 KiB (8 MiB).
 Changing this to 50 MiB avoids the segfault (although I have neither the
 patience nor the free disk space to see whether it runs to completion).

 While I doubt that this will be a genuine issue for many people, it can
 result in the upper limit on map dimensions being smaller than it could
 be.

 Consequently, we may want to think about whether the use of alloca()
 should be optional. Currently, it's used on any system which is believed
 to provide it (those which lack it use malloc/free). See the top of
 include/defs/gis.h for the details.

 If most users can live with the existing behaviour (an 8 MiB default stack
 allows for just short of a million columns with DCELL data) and most of
 the rest can live with explicitly increasing the stack size, it may
 suffice to just add e.g. "#ifndef DONT_USE_ALLOCA" to allow the remainder
 to override the behaviour at compile time.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2676#comment:4>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list