Re: flist -- "Killed" -- oom (*not* 1.8 related)

[Greg Minshall]

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