Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Kernel is quitting on me


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


  • Prev by Date: Re: UNDO and Mathematica - how useless is it?
  • Next by Date: Re: Re: Selecting left hand sides from assignments
  • Previous by thread: Re: Kernel is quitting on me
  • Next by thread: Re: Re: Kernel is quitting on me