Ken, > If you run under the debugger, you should stop when you receive the signal > from the OOM process.
thanks. OOM is a pretty strange way to die... ---- run -sequence xyz -all Starting program: /usr/bin/flist -sequence xyz -all [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) where No stack. ---- as for valgrind (which really is a wonderful contribution to software development!) ---- bash archlinux (master): {50084} valgrind flist -sequence xyz -all ==729147== Memcheck, a memory error detector ==729147== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==729147== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==729147== Command: flist -sequence xyz -all ==729147== ==729147== Warning: set address range perms: large range [0x59c8e040, 0xa313d8ac0) (undefined) Killed bash archlinux (master): {50085} ---- again, the way the OOM system kills you i guess doesn't leave even footprints. > Otherwise you could run under valgrind (it should be available in the > packaging system for your distro) which should very quickly tell you > where memory is leaking. the "set address range perms" does seem large. one stackoverflow description: ---- https://stackoverflow.com/a/13561685/1527747 ---- so, maybe that is ---- bash archlinux (master): {50088} dc -e '10o 16i A313D8AC0 59C8E040 - p' 42269452928 ---- hmm ... 42GB of memory? if that jogs anyone's memory, please let me know. otherwise (assuming this condition persists), i'll eventually try looking at the code and etc. (if anyone thinks of any syscalls that flist and friends might be making that might change these memory permissions, that would be of use, as my memory of memory is slight.) cheers, Greg