<div dir="ltr">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..<br><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>