* fix(ghidra): report kernel OOM kills as a memory constraint
A kernel or container OOM killer ends Ghidra with SIGKILL and prints no
java.lang.OutOfMemoryError, so the failure fell through to the generic
execution_failure that points at `rea doctor`.
On Linux with cgroup v2, read the process's own memory.events oom_kill
count before launch and again after a SIGKILL. When it rose, project
resource_constraint (memory) with the group's memory.max, and advise on
the whole process tree (native decompiler processes included) instead of
a larger Java heap. Otherwise name the signal as a possible OOM kill.
Fixes#5859
* fix(ghidra): scope OOM-kill attribution to what the cgroup proves
Review follow-up for the SIGKILL projection:
- The process supervisor records stop_requested before it sends any
signal, and Ghidra diagnostics carry it, so a SIGKILL from REA's own
stop is never reported as an outside kill. Only process and protocol
failures qualify; launcher (start) failures can include REA's rollback.
- Word the memory constraint as an OOM kill in REA's cgroup or a child
group; the count is per cgroup, not per process tree.
- Keep the open_binary reopen guidance for an established session.
- Resolve the cgroup directory through the cgroup2 mount in
/proc/self/mountinfo, so subtree mounts are joined from their root,
and read kernel files to EOF within a budget.
- Report memory_max as "max" for an unlimited group and null only when
the limit could not be read.
Akshat Gupta
960b742581