Re: Re: Kernel is quitting on me
- To: mathgroup at smc.vnet.net
- Subject: [mg97929] Re: [mg97913] Re: [mg97851] Kernel is quitting on me
- From: Sseziwa Mukasa <mukasa at gmail.com>
- Date: Thu, 26 Mar 2009 05:19:15 -0500 (EST)
- References: <gq54vc$80f$1@smc.vnet.net> <200903230903.EAA27073@smc.vnet.net> <200903241028.FAA19615@smc.vnet.net> <C51BCA18-5E5C-4F34-B23A-F928705DAB7A@jeol.com> <200903251045.FAA24645@smc.vnet.net>
On Mar 25, 2009, at 6:45 AM, Fernando Cucchietti wrote:
> Thanks Sseziwa,
>
> yours was a very useful answer. I was also afraid that there could be
> a memory leak somewhere. However, I don't know how to track down the
> offending code. Any ideas?
Sorry, I don't have any clever ideas on how to approach the problem.
In my specific case my code looked like this:
nfft[f_,w_,opts___?OptionQ] :=
Module[{m,a,psi,c,n,g,l,dims,ret},
(*deleted for clarity*)
g =
Fourier[
RotateLeft[
PadLeft[
PadRight[
(*Step 1: Compute ghat=f/c*)
Fold[Transpose[#1/#2,Prepend[Range
[1,ArrayDepth[#]-1],
ArrayDepth[#]]]
&,f,
If[c===None,precomputec
[n,nfft`approximationWidth->m,
nfft`oversamplingFactor->a],c]],
Quotient[n,2]+Quotient[Dimensions[f],2]+Mod
[n,2]],n],
Quotient[n,2]],
FourierParameters->{1,-1}];
ret=(*deleted for clarity*);
Remove[g];Return[ret]]
And g turned out to be the problematic variable. This was discovered
with the help of Wolfram Technical Support. Including the deleted
code the module isn't particularly large but it is complex. Looking
back at my conversation with technical support it seems I narrowed
down the problem as follows: I had code that crashed at random times
as you do, I started checking the amount of memory used before and
after calls to routines I found suspicious and noticed that the
module above (without the remove) caused MemoryInUse to grow rapidly
after each call. I then sent the problematic code to technical
support who identified g as the variable that caused the memory
leak. So to remove the leak I only had to Remove[g], your case may
be different.
> I Remove-d all variables from my modules (which were all properly
> defined as local anyway), except the one that gets returned as the
> output of the module. How could I do that?
You can't, originally my code didn't have a variable to return the
results, but I had to introduce one since I could free the memory
associated with g before returning.
> There are also "hidden"
> variables created inside each Module when computations are made, I
> guess I have to pray for those to be disposed of.
At this point I think you'd need to refer to technical support, they
have the tools to inspect more deeply where the memory is being
leaked, but as you pointed out earlier they are unlikely to comb
through large amounts of code for you, so if you can narrow the leak
location(s) down at least in my experience they can be helpful.
> Do you think that renaming all variables from all modules so that
> there are no two variables named the same could help? I mean, even if
> they are local to the module, could they collide and cause the leak?
My problem didn't seem to arise from name collision, there were no
variables named g in a scope level outside of the module.
Good luck,
Ssezi
- References:
- Re: Selecting left hand sides from assignments
- From: Raffy <raffy@mac.com>
- Kernel is quitting on me
- From: Fernando Cucchietti <fernando.cucchietti@icfo.es>
- Re: Kernel is quitting on me
- From: Fernando Cucchietti <fernando.cucchietti@icfo.es>
- Re: Selecting left hand sides from assignments