[GRASS-dev] r.univar, ERROR G_realloc:
peter.zamb at gmail.com
Sat Dec 7 00:47:16 PST 2013
On Fri, Dec 6, 2013 at 11:58 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>> D1/1: G_find_raster(): name=MASK mapset=pietro
>> Current region rows: 28545, cols: 27645
>> ERROR: G_realloc: unable to allocate 68000 bytes of memory at
> Don't use "r.univar -e", particularly for large maps. r.quantile and
> r.statistics3 are far more efficient.
ok, thanks I will look into it!
>> Maybe is a stupid idea but since I had some problems also with
>> v.build, do you think that could be possible that the problem is due
>> not to the GRASS code, but to my physical memory that maybe is damaged
>> in some sector?
> That's unlikely. Is the OS recognising that you have 24 GiB of RAM?
yes it is.
> Are you allowed to use all (or most) of it for a single process (check
> the output from "ulimit -a")?
I think so:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 30
file size (blocks, -f) unlimited
pending signals (-i) 192592
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 192592
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Actually running Memtest86, to test the memory bank I found hundred of
errors so I strongly believe that the problem is due to some physical
More information about the grass-dev