[GRASS-dev] [GRASS GIS] #1662: Caching bug in 3D raster library with large data

Sören Gebbert soerengebbert at googlemail.com
Mon Aug 26 11:54:44 PDT 2013


Sorry for replying directly to the list, but the grass trac server
seems to be down or very, very busy.

Replying to [comment:4 annakrat]:
> I tested it on 32Bit Ubuntu and I get a segmentation fault after 100% is finished. Should I test something else?

Many thanks for the test.

Can you please run the test in the gnu debugger (gdb) again, so that i
can get an idea of what the reason for the segfault is? You can
create a backtrace after the segfault occurred with "bt" in the gdb
session.

Example:

{{{
gdb test.g3d.lib

r unit=large
..... segfault
bt
}}}

Can you then please provide the output of the backtrace command "bt"?

2013/8/26 GRASS GIS <trac at osgeo.org>:
> #1662: Caching bug in 3D raster library with large data
> -------------------------------------+--------------------------------------
>  Reporter:  huhabla                  |       Owner:  grass-dev@…
>      Type:  defect                   |      Status:  new
>  Priority:  critical                 |   Milestone:  7.0.0
> Component:  Raster3D                 |     Version:  svn-trunk
>  Keywords:  3D raster, tiles, cache  |    Platform:  Linux
>       Cpu:  x86-32                   |
> -------------------------------------+--------------------------------------
>
> Comment(by annakrat):
>
>  I tested it on 32Bit Ubuntu and I get a segmentation fault after 100% is
>  finished. Should I test something else?
>
> --
> Ticket URL: <http://trac.osgeo.org/grass/ticket/1662#comment:4>
> GRASS GIS <http://grass.osgeo.org>
>


More information about the grass-dev mailing list