[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] WS FULL problem

From: Elias Mårtenson
Subject: Re: [Bug-apl] WS FULL problem
Date: Fri, 17 Jun 2016 23:29:11 +0800

No. It's a system wide setting. The concept is called overcommit, and most of the details seem to be covered in this Serverfault question: http://serverfault.com/questions/362589/effects-of-configuring-vm-overcommit-memory


Hi Elias,

interesting, thanks. Do you by chance know the name of the config option?

Or is it a
mallopt() setting?

/// Jürgen

On 06/17/2016 03:08 PM, Elias Mårtenson wrote:

If you are running put if RAM+swap on the machine, a default Linux installation will not return NULL from malloc(). Instead, it will simply kill the process when it tries to access the memory (actually, when it attempts to map in a memory page, and the mapping operation fails). This is likely what happens here.

You can configure Linux to act sanely, but if you do so, you also need to make sure you have plenty of swap, or you will not be able to actually use all your RAM.


On 17 Jun 2016 14:50, "Juergen Sauermann" <address@hidden> wrote:
Hi Blake,

if I start apl directly then it seems like GNU APL behaves properly (I tried your
examples and always got a WS FULL).

I could imagine, though, that your shell (resp. script) is killing APL when APL
tries to allocate too much memory (and APL can then do little about it).

It would be interesting by which signal APL is killed (try ulimit -c unlimited (e.g using bash)
to get a core file and then look at the core with gdb). I could then install a signal handler (if
the signal is catch'able) to fix this.

The question right now is if apl is killing itself (e.g. by an uncaught exception) or is being
killed from its environment.

I would also be good to check (ulimit -a inside the script) if there are any active limits related
the memory size.

/// Jürgen

On 06/16/2016 08:59 PM, Blake McBride wrote:
Sometimes, when you have, essentially, a WS full situation, GNU APL just dies instead of giving a WS FULL error.

/home/blake/bin/apl: line 3:  7341 Done                    akt
      7342 Killed                  | /usr/local/bin/apl "$@"
address@hidden ~ $ apl
/home/blake/bin/apl: line 3:  7964 Done                    akt
      7965 Killed                  | /usr/local/bin/apl "$@"
address@hidden ~ $ apl
      ^ ^

address@hidden ~ $ apl
/home/blake/bin/apl: line 3:  7992 Done                    akt
      7993 Killed                  | /usr/local/bin/apl "$@"

reply via email to

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