[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]