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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev