[GRASS-dev] Addons: r.sun2 segfault

[Glynn Clements]

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,
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.

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. 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).

But more generally, there are so many things wrong with that code that
dealing with specific bugs is just papering over the cracks.

-- 
Glynn Clements <glynn at gclements.plus.com>