On Fri, Dec 6, 2013 at 11:58 PM, Glynn Clements <[email protected]> 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. _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
