In general, DrRacket does not promise to avoid this situation. Let me explain a little bit. This program is effectively equivalent to this one:
#lang racket/base (define (run l) (run (cons 'x l))) (run '()) (but running at compile time, which is why things happen automatically, but lets leave that aside for now). So when you run that program, DrRacket is asking the operating system for all of its memory. At some point, the operating system says "sorry, no, we're out of memory" and since the program running inside DrRacket doesn't really care that we're out of memory, the operating system responds with "die!". And so DrRacket dies. There are two ways we try to do better. First: we can set limits on the memory. But if the limit is set to be higher than the amount of memory available on the machine, then it is as if the memory limit isn't set. Also worth noting at this point: the way that DrRacket's counting of "how much memory" is only loosely related to the way that your machine's vendor or the OS counts. There are some constant factors of difference there that depend on things like how the garbage collector is configured and how many other programs are running on your system and what they are doing (like the OS itself likes to have some of the memory and it (quite reasonably) doesn't want to share that memory). The second way is that the OS will sometimes say "you are about to cause me to exhaust all of the system's memory and if you do that, I will kill you" at which point the GC inside Racket responds with "okay, I'll just die first". The main advantage of this is that you get an error message saying "out of memory" from Racket instead of an error message saying "I killed your program" from the OS (which is the message you're getting). It turns out to be remarkably difficult to get this error message to work in all situations. We're better than we used to be at it, but at some level, the best we can do in that case is really just to change the text of the error message. When we're out of memory like that, it's very very hard to recover if the limits are not set up ahead of time (i.e. back to the previous paragraph). I hope this clears up the issue somewhat. In the meantime, I suggest you lower the memory limit for your machine. Robby On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson <jonstener...@comcast.net> wrote: > Actually you don't even have to run the program. With memory limit set to > 1024, just open a file containing the expression and wait. After a minute or > two DrRacket puts up a MSVC runtime error dialog. > > > On 2/5/2016 9:39 AM, jon stenerson wrote: >> >> Setting the limit lower helped. Thanks. I did not see that message about >> Background Expansion Terminated before. Now I do. >> >> Jon >> >> On 2/5/2016 6:55 AM, Robby Findler wrote: >>> >>> It took a while for mine for the custodian limit to be reached and for >>> the expansion to run out of memory. It may be that the threshhold for >>> the memory use is too high on some systems. Maybe the right thing is >>> to set the default a bit lower? >>> >>> Jon: if you open the "Racket" menu you should see a "Limit Memory..." >>> menu item. How does DrRacket do if you change the number in there to >>> 256 and then paste the program into the definitions window? Do you see >>> the red message at the bottom of the screen or does DrRacket still run >>> out of memory? >>> >>> Anthony: I don' thave a good solution for you, but I find that the >>> menu key short cut (control-k for you?) for killing is more likely to >>> get thru, because it requires a lot less event handling than the >>> others. >>> >>> Robby >>> >>> >>> On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi <olopie...@gmail.com> >>> wrote: >>>> >>>> On my system it behaves almost exactly as described by Jon (6.3, >>>> windows). >>>> >>>> The one difference is that DrRacket hasn't crashed yet, but the Task >>>> manager reports one processor at 100% and memory use slowly growing. >>>> Currently is at 7.5 GB. >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico <acarr...@memebeam.org> >>>> wrote: >>>>> >>>>> On 02/05/2016 08:01 AM, Robby Findler wrote: >>>>>> >>>>>> When I run this, I see a message at the bottom of the DrRacket window >>>>>> (in red): >>>>>> >>>>>> Background expansion terminated abnormally (out of memory) >>>>>> >>>>>> do you see this message? >>>>> >>>>> I tried too, and it stops fine with the same message as Robby. No >>>>> phantom CPU usage apparent. >>>>> >>>>> However, I did have a run away DrRacket recently that didn't respond to >>>>> stop and took a few minutes to kill because my UI was extremely >>>>> sluggish >>>>> (partially because X11 and/or the window manager sucks, and my CPU >>>>> probably throttled, but still...). I don't have any good data for you >>>>> about the circumstances of the issue though. >>>>> >>>>> -- >>>>> Anthony Carrico >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Racket Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to racket-users+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Racket Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to racket-users+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
