|
From: | Elias Mårtenson |
Subject: | Re: [Bug-apl] WS FULL problem |
Date: | Fri, 17 Jun 2016 21:08:35 +0800 |
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.
Regards,
Elias
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.
x←⍳100000000x[10000]←445y←x/home/blake/bin/apl: line 3: 7341 Done akt7342 Killed | /usr/local/bin/apl "$@"address@hidden ~ $ aplx←⍳100000000/home/blake/bin/apl: line 3: 7964 Done akt7965 Killed | /usr/local/bin/apl "$@"address@hidden ~ $ aplx←⍳10000000⍴x10000000y←xx←⍳10000000x←⍳100000000WS FULLx←⍳100000000^ ^)off
address@hidden ~ $ aplx←⍳100000000/home/blake/bin/apl: line 3: 7992 Done akt7993 Killed | /usr/local/bin/apl "$@"
[Prev in Thread] | Current Thread | [Next in Thread] |