Matthew's usual trick for tracking down memory leaks is to put a will-executor into your data structure (the one you think is leaking) and then use one of the alternative collectors that lets you track down all of the paths from a root to the will-executors in the system. Identify yours and why there is a connection. (You can do this with any primitive type, but will-executors are relatively unused so that's why they tend to work well.)
This isn't the easiest job, tho ... Robby On Thu, Feb 19, 2009 at 5:28 PM, Carl Eastlund <cce at ccs.neu.edu> wrote: > I see. And yes, thinking about it now, I have a suspicion where the > Dracula/ACL2 communication may be running up large amounts of memory. > I'll keep it in mind if this happens again. Thanks for the > suggestion. > > --Carl > > On Thu, Feb 19, 2009 at 6:22 PM, Robby Findler > <robby at eecs.northwestern.edu> wrote: >> I'm saying you got that message because your program allocated too much. >> >> Robby >> >> On 2/19/09, Carl Eastlund <cce at ccs.neu.edu> wrote: >>> There are two notions of out of memory... there's the case where the >>> computer is literally out of memory, and there is the case where >>> DrScheme has hit the artificial limit imposed by the "Scheme > Limit >>> Memory ..." menu option. When DrScheme hits the artificial limit, it >>> offers the user the chance to raise the memory limit. I have no such >>> artificial limit set, and DrScheme offered no such option. >>> >>> I thought you were saying that my error likely came from check syntax >>> because otherwise I would have hit an artificial limit earlier and >>> been offered the chance to raise the limit. I was saying that I don't >>> have that limit set, so I can run out of memory completely even from >>> the regular "run" button. >>> >>> If that's not what you were getting at, now I'm confused about what >>> you were saying. >>> >>> --Carl >>> >>> On Thu, Feb 19, 2009 at 6:11 PM, Robby Findler >>> <robby at eecs.northwestern.edu> wrote: >>>> That is the out of memory message no ...? I'm confused. >>>> >>>> On 2/19/09, Carl Eastlund <cce at ccs.neu.edu> wrote: >>>>> I have memory limits turned off anyway, because it used to be that if >>>>> I ran something that triggered a planet package install the memory >>>>> limit would crash the install and leave my planet cache in a bad >>>>> state. It may be that's no longer the case, and I should put the >>>>> memory limit back on. Nevertheless, since I run with unlimited >>>>> memory, the fact that I ran out before I hit an artificial limit >>>>> doesn't indicate where the bug happened. >>>>> >>>>> --Carl >>>>> >>>>> On Thu, Feb 19, 2009 at 4:34 PM, Robby Findler >>>>> <robby at eecs.northwestern.edu> wrote: >>>>>> I asked because check syntax doesn't install memory limits when it >>>>>> runs, only run does. Perhaps your tool is doing the same thing? >>>>>> >>>>>> Robby >>>>>> >>>>>> On Thu, Feb 19, 2009 at 2:58 PM, Carl Eastlund <cce at ccs.neu.edu> >>>>>> wrote: >>>>>>> No, though I might have just triggered the theorem prover, which uses >>>>>>> the same hook to compile the program as check syntax >>>>>>> (drscheme:eval:expand-program), if that's relevant. >>>>>>> >>>>>>> --Carl >>>>>>> >>>>>>> On Thu, Feb 19, 2009 at 3:32 PM, Robby Findler >>>>>>> <robby at eecs.northwestern.edu> wrote: >>>>>>>> Were you running check syntax? >>>>>>>> >>>>>>>> Robby >>>>>>>> >>>>>>>> On Thu, Feb 19, 2009 at 2:28 PM, Carl Eastlund <cce at ccs.neu.edu> >>>>>>>> wrote: >>>>>>>>> DrScheme gave me the error message in the subject -- I wish I had >>>>>>>>> copied or screenshotted it, but I was so surprised to see it I just >>>>>>>>> clicked "OK" to see what it would do, so I may have the wording >>>>>>>>> slightly wrong. Anyway, DrScheme promptly crashed (and Mac OS gave >>>>>>>>> me >>>>>>>>> to "quit unexpectedly dialog") when I hit "OK". >>>>>>>>> >>>>>>>>> I don't recall doing anything intensive when that happened, I was >>>>>>>>> just >>>>>>>>> running a program I had run before (in Dracula). Anyone know what >>>>>>>>> might have happened, or what further information I should look for to >>>>>>>>> help diagnose this? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Carl Eastlund >
