[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
results.
>
>
>
>
--
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