[racket] DrRacket 6.1 or Hardware Issue?

1. Generally, requests to allocate memory will succeed even when RAM is
full and the system is deep into swap. Random access over a set of pages
that cannot all fit into RAM results in "thrashing": continuously
swapping pages out to the disk and reading other pages in. This can make
the system unusable, and is independent of Racket. I'm not sure how GHC
decides to terminate with the "too much memory requested" error, but I
speculate it's a self-imposed limit perhaps based on the amount of
accessible RAM.

2. I strongly doubt the issue is related to your memory configuration.
If applications run well at normal memory pressure and the system is
generally stable, the problem is likely caused by plain old swap
thrashing. You could try booting off some Linux install disk and running
memtest86+ to be sure.

3. I think implementing a time and memory limit for each background
expansion attempt is a good idea.

I don't know about the unreclaimable memory. That seems like a bug.

On Mon, Sep 08, 2014 at 05:23:59PM -0400, Sean Kanaley wrote:
> After investigating a near complete lock up some more (saved by TTY window
> and killing DrRacket after seeing it with 3GB+ residency), it's clearly
> correlated with background expansion of an accidentally infinitely looping
> macro. A few questions..
> 
> 1. Is the OS supposed to break and enter an infinite swap loop? If that is
> just a fact of life for a program requesting too much memory simultaneously
> (and an ever increasing amount), well for example ghc just shuts itself
> down claiming "too much memory requested" or something like that.
> 
> 2. Is this related to my very long time ago issue where I removed a bad 1GB
> from the 3rd slot, lazily leaving the 4th slot where it is, causing me to
> have 3GB instead of 4, even though it's "supposed to" have 4 based on the
> max slot (I have never encountered this sort of system freeze before
> however)? Maybe the OS would more gracefully handle the paging?
> 
> 3. Can DrRacket simply realize it's expanding the same thing and not demand
> infinite memory (I don't understand the system on the implementation level,
> sorry if that's off base).
> 
> The solution, aside from me not writing incorrect macros is to disable
> background expansion. Relatedly, DrRacket doesn't seem able to reclaim this
> space without being restarted. Closing the file and clicking the garbage
> collection thing only recovers say 20MB out of 2GB if I turn off expansion
> before the OS locks.
> 
> Lastly, a related possible bug I've encountered since 6.1 is the infinite
> garbage collection loop, where the OS remains responsive but DrRacket has
> to be restarted, but this one I have no idea where it comes from only that
> it seems to happen after a while, and fairly reliably so.

> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users