[GRASS-dev] Addons: r.sun2 segfault

Markus Neteler neteler at osgeo.org
Tue Oct 21 18:15:47 EDT 2008


On Tue, Oct 21, 2008 at 11:54 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Neteler wrote:
>
>> Working on a large DEM, r.sun2 (addons) segfaults for me:
>
>> #0  INPUT_part (offset=0, zmax=0x7fffc45840a8) at main.c:965
>> #1  0x0000000000405d6e in calculate (singleSlope=<value optimized out>, singleAspect=<value optimized out>,
>>     singleAlbedo=<value optimized out>, singleLinke=<value optimized out>,
>
>> As so often, I get lost in the gdb output :)
>
> Start by compiling without optimisation. If optimisation is enabled,

ouch - sorry about that. It's the version which I use on a cluster,
I forgot to disable optimisation.

> you still get a backtrace, but real debugging becomes practically
> impossible, as the compiled code typically bears little or no
> resemblance to the source code.

Sure - with no optimisation and G_malloc() I get a
ERROR: G_malloc: out of memory

(easier to understand...)

> However, looking at the numbers:
>
> horizonarray = malloc(arrayNumInt * numRows * n);
>
> m = cellhd.rows = 19509
> n = cellhd.cols = 23522
> horizonStep = 15
> arrayNumInt = 360 / horizonStep = 360/15 = 24
> numPartitions = 1
> numRows = m / numPartitions = 19509 / 1 = 19509
> arrayNumInt * numRows * n = 24 * 19509 * 23522 = 11,013,376,752
>
> So the horizon array works out at ~11GB.

The machine has 8GB RAM + 2GB swap.

> Personally, I would start by
> checking that horizonarray is non-null (note that it uses malloc(),
> not G_malloc(), so there's no error checking).

Running it on a different machine with 16GB RAM it starts and
then crashed at 0.x%:

(gdb) r -s pat_dtm_5m horizon=horangle horizonstep=15
aspin=pat_dtm_5m.as slopein=pat_dtm_5m.sl day=180
insol_time=photoperiodo_d180
Starting program: /home/neteler/binaries/grass-6.4.svn/bin/r.sun2 -s
pat_dtm_5m horizon=horangle horizonstep=15 aspin=pat_dtm_5m.as
slopein=pat_dtm_5m.sl day=180 insol_time=photoperiodo_d180
[Thread debugging using libthread_db enabled]
Mode 2: integrated daily irradiation
[New Thread 47358322518032 (LWP 1627)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47358322518032 (LWP 1627)]
0x0000000000404fb8 in INPUT_part (offset=0, zmax=0x7fff33a95a38) at main.c:979
979                         horizonpointer[i] = (char)(rint(SCALING_FACTOR *
(gdb) bt
#0  0x0000000000404fb8 in INPUT_part (offset=0, zmax=0x7fff33a95a38)
at main.c:979
#1  0x00000000004076ac in calculate
(singleSlope=3.6565798448710657e-319,
singleAspect=1.90389130408995e-314,
    singleAlbedo=0.20000000000000001, singleLinke=3, gridGeom=
      {xp = 6.9531864307740289e-310, yp = 1.0909214257054157e-312, xx0
= 0, yy0 = 2.3398120197805848e-310, xg0 = 2.339812019231579e-310, yg0
= 2.0760929936980226e-317, stepx = 5, stepy = 5, deltx = 117610, delty
= 97545, stepxy = 5, sinlat = 2.3398112026541087e-310, coslat =
6.9531864307767956e-310}) at main.c:1880
#2  0x0000000000404457 in main (argc=9, argv=0x7fff33a95df8) at main.c:759
(gdb)

Running "top" in parallel, I see that no more than 23% of RAM are used
when it crashes.

Adding
  -m   Use the low-memory version of the program
does not help.

Markus


More information about the grass-dev mailing list