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

GRASS GIS trac at osgeo.org
Sat Jun 18 13:52:37 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 annakrat):

 Replying to [comment:11 escheper]:
 > Remains the following questions:
 > - How are other GRASS modules dealing with large grids? Do they have the
 same problem?
 > - What will be the impact on the output raster after changing some "="
 to "=="? Do we get different result buffers?
 > - In what way should I do a "pull request" of my changes in de code?

 [https://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs Create a diff] and
 attach it here. You can make it simpler for us if you first identify the
 exact source of the error and then upload the patch which fixes without
 any extra changes. Changing int variables to long int might result in
 spending too much memory, so you shouldn't change it unless you consider
 the consequences.

 If you think there are other changes which need to be done to run r.buffer
 correctly, please explain them. For example, it's not clear why "=="
 should replace "=" and where. And yes, very probably we get then different

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

More information about the grass-dev mailing list