[GRASS-dev] r.univar, ERROR G_realloc:

[Pietro]

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
>>        r.univar_main.c:327
>
> 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
problem.