[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A naughty function call
From: |
Bob Proulx |
Subject: |
Re: A naughty function call |
Date: |
Mon, 19 Jul 2021 02:14:26 -0600 |
Wolfgang Laun wrote:
> On my Linux box running GNU Awk 5.0.1, the execution fails:
> $ gawk -f srepDoubl.awk
> Killed
As Arnold noted that's likely the OOM Killer. Check your system log
for oom-killer messages. Here is a recent example from the debbugs
server that I looked at just a short time ago. Just for an example.
...
Jul 18 10:04:12 debbugs kernel: [41161093.554645] soap.cgi invoked
oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Jul 18 10:04:19 debbugs kernel: [41161100.099448] /usr/sbin/apach invoked
oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
...
> In this simple example, it is immediately clear to the programmer that
> memory allocation fails. But is this the intended diagnostic? I think it
> might be a little more user-friendly.
...
> PS: It seems preferable to measure the performance using repeated
> executions of the function call with *reasonable *parameter combinations.
I always disable Linux Memory Overcommit so that programs will get a
malloc() failure or fork() failure instead of simply getting a kill -9
and being removed from the kernel's run queue. And then the correct
process is handling the memory stress issue. With the OOM Killer it
occasionally kills the wrong process!
And as you know the SIGKILL signal cannot be trapped by the program.
man 7 signal
Signal Standard Action Comment
SIGKILL P1990 Term Kill signal
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
Effectively the Linux kernel simply removes the process from the run
queue. The gawk interpreter process has no ability to do anything.
Bob