I was actually printing every 10 seconds how much memory it was using, the last before got killed was:

  PID    VSZ   RSS     TIME     ELAPSED %CPU %MEM COMMAND
 4097 4938188 2445712 00:22:44    25:04 90.7 15.0 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7

Provided I have 16GB RAM then maybe it was really some limit in the Bourne shell or OS which prevented DUMA to obtain more memory. But my own python-based app can can grow to even 12GB RSS on this computer so I wonder what limit would be the cause. Probably some overhead due to DUMA.



I increased shell limits and looks it can continue further so far:

vostro crashtest # ulimit -l unlimited
vostro crashtest # ulimit -s unlimited
vostro crashtest # ulimit -i unlimited
vostro crashtest # 
vostro crashtest # ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
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) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127104
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
#


Currently the emerge through DUMA is at:

  PID    VSZ   RSS     TIME     ELAPSED %CPU %MEM COMMAND
 9528 6121764 3041960 00:34:16    56:05 61.1 18.6 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7

and still continues ...


Sorry, should better read the main STDERR output before diving into gdb stacktraces. I thought those negative numbers are a true sign of an error. ;)