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