[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