memory leak help!
in [Fortran]
|
Prev: Internal compiler error when both using and passing an intrinsicfunction
Next: User types + interface in the same module
From: pacman on 17 Jun 2008 08:58 On Jun 17, 12:42 am, Arjen Markus <arjen.mar...(a)wldelft.nl> wrote: > On 17 jun, 09:06, julesr <julesrei...(a)yahoo.co.uk> wrote: > > > Hi, > > It seems I have a memory leak. I've got no allocate/deallocate > > problems, and can't figure out what else it could be. Does anyone have > > any tips about other common sources of leaks? > > I'm compiling from LaheyED4W, and it's got it's deallocate option > > turned on. > > > Any help would be great! > > thanks > > julesr > > Can you tell us a bit more about your program? > Maybe show some pieces of code. > > How did you find out that you do have memory leaks? > > Regards, > > Arjen Valgrind may be a good choice for finding memory leaks. http://valgrind.org/
From: Paul van Delst on 17 Jun 2008 09:11 julesr wrote: > Hi, > It seems I have a memory leak. I've got no allocate/deallocate > problems, and can't figure out what else it could be. Does anyone have > any tips about other common sources of leaks? > I'm compiling from LaheyED4W, and it's got it's deallocate option > turned on. Do you have any subprogram pointer (or derived types containing pointers) dummy arguments with the INTENT(OUT) attribute? If so, and if the pointers of the actual argument(s) are associated upon entry to the subprogram, that could be the source of a memory leak. But, as Arjen said, we need more info to provide more that educated guesses. cheers, paulv
From: julesr on 17 Jun 2008 20:48 Hi, thanks for the responses. I don't have any pointers in my program at all...you have to declare them as type POINTER, right? which I haven't. I have no dynamic arrays (I got rid of them all). The only part of my code that I'm not sure about has PARAMETER and DATA statements - I'll paste that below. It's a random number generator from numerical recipes. As for other parts of my code....there are many lines, and i'm not sure where the problem is, so it's hard to know what to post. Actually, I know roughly where it must be, so I'll post the type declaration statements from those sections and see if you think anything's suspicious. The reason I think I have a memory leak is that as the program loops, the memory it's using builds until it crashes. This is according to Task Manager in Windows, which I know probably isn't that accurate, but surely it tells me enough.... In what you said above about dummy arguments with INTENT(OUT) attributes, that was just to do with pointers, right? I have lots of INTENT(OUT)s, but none of them are pointers. So again, thanks for the help, it's much appreciated!! Here are some scraps of code: the function similarity is called from within a loop of the main program. similarity then calls subroutine RRMod from within a loop. When the number of calls to RRMod increases, the problem gets worse. ----------------------------- REAL FUNCTION similarity(nopt,x,Att,ngauge,ids,num_mod_pars,modpar,obj,Qdays_all,Pdays_all,ncont) IMPLICIT NONE CHARACTER*70 :: filrun,filapet INTEGER, INTENT(IN) :: ncont INTEGER, INTENT(IN) :: ngauge CHARACTER*6 :: ids(ngauge) INTEGER, INTENT(IN) :: nopt REAL, INTENT(IN) :: x(nopt) REAL :: obj(ngauge) REAL :: S(ngauge),S1(ngauge) INTEGER :: SP(ngauge),SP1(ngauge) REAL, INTENT(IN) :: Att(ngauge,7) INTEGER :: ierror,allocstat REAL :: WSim(ncont),WObj(ncont),Weight(ncont) REAL :: sum_WSim,max_WSim,sum_WObj,sum_Weight INTEGER, INTENT(IN) :: num_mod_pars REAL :: pars(ncont,num_mod_pars) REAL :: modpar(ngauge,num_mod_pars) REAL :: Qobs REAL :: apet(12,2) INTEGER :: Qdays_all(ngauge),Pdays_all(ngauge) REAL :: NSE_all(ngauge),NSE,NSE_all1(ngauge) INTEGER :: i,j,k INTEGER :: nlines,Qdays,Pdays INTEGER :: arrsize do i=1,ngauge !..........lines of code...... call hpsort(ngauge,S,SP,S1,SP1) ! sorts S and SP, returning S1 and SP1 (hpsort type declarations below) !..........lines of code...... call RRMod(NSE,pars,Weight,ncont,Qdays,Pdays,apet,num_mod_pars,ids(i),filrun) ! RRMod returns NSE end do call hpsort2(ngauge,NSE_all,NSE_all1) ! sorts NSE_all, returns NSE_all1 - exactly the same as hpsort but without the pointing array !(which is not of type POINTER!! !....lines of code, similarity assigned a value and returns to main prorgrma END ------------------------------------- SUBROUTINE RRMod(NSE,pars,Weight,ncont,Qdays,Pdays,apet,num_mod_pars,id,filrun) IMPLICIT NONE INTEGER, INTENT(IN) :: ncont,Qdays,Pdays,num_mod_pars REAL, INTENT(IN) :: pars(ncont,num_mod_pars) REAL, INTENT(IN) :: Weight(ncont) REAL, INTENT(IN) :: apet(12,2) REAL :: P(Pdays,4) INTEGER :: i,z REAL :: sms,gw REAL :: et REAL :: dt,c0,c1,c2,fip,fop,fdr REAL :: pa,aet1,rinfcap,runsur,rinfil,runint,rech,gw1,runbas,aet2 REAL :: rtot,fin,fon INTEGER :: ix REAL :: Q1 REAL :: Q(Qdays) CHARACTER*70 :: filrain CHARACTER*70, INTENT(IN) :: filrun CHARACTER*6 :: id INTEGER :: ierror, arrsize,allocstat REAL, INTENT(OUT) :: NSE !......lines of code, loops, nothing extra called.... ! returns NSE to calling function similarity END --------------------------------------------------------- !------------------------------------------------------------------ ! Uses the heapsort algorithm, from Numerical Recipes SUBROUTINE hpsort(n,ra,rap,outi,outip) IMPLICIT NONE INTEGER :: n ! size of array ra REAL :: ra(n) ! array to be sorted REAL, INTENT(OUT) :: outi(n) ! sorted rearrangement INTEGER :: rap(n) ! pointing array (not of type POINTER!!) INTEGER, INTENT(OUT) :: outip(n) ! pointing array rearrangement INTEGER :: i,ir,j,l REAL :: rra,rra1 INTEGER :: arrsize !......lines of code....... ! returns outi and outip to calling function similarity END -------------------- here is the random number generator, called from the main program, from within a loop, but I don't think this is the problem: REAL FUNCTION ran1(idum) INTEGER :: idum,IA,IM,IQ,IR,NTAB,NDIV REAL :: AM,EPS,RNMX PARAMETER (IA=16807,IM=2147483647,AM=1./ IM,IQ=127773,IR=2836,NTAB=32,NDIV=1+(IM-1)/NTAB,EPS=1.2e-7,RNMX=1.- EPS) ! "minimal" random number generator of park and miller with bays- durham shuffle and added safeguards. ! returns a uniform random deviate between 0.0 and 1.0 (exclusive of the endpoint values). Call with idum ! a negative integer to initialise; thereafter, do not alter idum between successive deviates in a sequence. RNMX should approximate ! the largest floating value that is less than 1. INTEGER :: j,k,iv(NTAB),iy SAVE iv,iy DATA iv /NTAB*0/, iy /0/ if (idum.le.0) then ! initialise idum=MAX(-idum,1) ! prevent idum = 0 do j=NTAB+8,1,-1 ! load the shuffle table after 8 warm-ups k=idum/IQ idum=IA*(idum-k*IQ)-IR*k if (idum.lt.0) then idum=idum+IM end if if (j.le.NTAB) then iv(j)=idum end if end do iy=iv(1) END if k=idum/IQ ! start here when not initialising idum=IA*(idum-k-IQ)-IR*k ! compute idum=mod(IA*idum,IM) without overflows by Schrage's method if (idum.lt.0) then idum=idum+IM end if j=1+iy/NDIV ! Will be in the range 1:NTAB iy=iv(j) ! Output previously stored value and refill the shuffle table iv(j)=idum ran1=MIN(AM*iy,RNMX) ! Because users don't expect endpoint values return END
From: Richard Maine on 17 Jun 2008 23:03 julesr <julesreichl(a)yahoo.co.uk> wrote: > I don't have any pointers in my program > at all...you have to declare them as type POINTER, right? No. Pointer is not a type (anyway, not on Fortran). However, you do have to declare the pointer attribute, so if you don't have any pointer declarations of one sort or other then you don't have any pointers. > I have no dynamic arrays (I got rid of them all). Yes you do. I noticed some automatic arrays in your declarations. Namely.. [wrapped for posting] > REAL FUNCTION > similarity(nopt,x,Att,ngauge,ids,num_mod_pars,modpar,obj,Qdays_all, > Pdays_all,ncont) .... > REAL :: obj(ngauge) [and a bunch of others] They should be ok, but they are dynamically allocated. (Well, Giles claims that the term "dynamic" doesn't apply to automatic arrays, but I disagree with him.) Regardless of what terminology one thinks appropriate, they are allocated and deallocated during execution. However, they aren't prime candidates for memory leaks. The stuff you were uncertain about, PARAMETER and DATA statements, are completely implausible as having anything to do with memory leaks. I'm afraid that it isn't very useful to study parts of the code that aren't where the problem is. You are violating rule number 1 of asking for debugging help, namely.. Show the actual data rather than your deductions, guesses, and descriptions. There is basically no data here for anyone to do anything useful with. You are far from alone in this failing. It is a very common failing in asking for debugging help. That's part of why it is rule number 1. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: julesr on 17 Jun 2008 23:43
On Jun 18, 1:03 pm, nos...(a)see.signature (Richard Maine) wrote: > julesr <julesrei...(a)yahoo.co.uk> wrote: > > I don't have any pointers in my program > > at all...you have to declare them as type POINTER, right? > > No. Pointer is not a type (anyway, not on Fortran). However, you do have > to declare the pointer attribute, so if you don't have any pointer > declarations of one sort or other then you don't have any pointers. > > > I have no dynamic arrays (I got rid of them all). > > Yes you do. I noticed some automatic arrays in your declarations. > Namely.. [wrapped for posting] > > > REAL FUNCTION > > similarity(nopt,x,Att,ngauge,ids,num_mod_pars,modpar,obj,Qdays_all, > > Pdays_all,ncont) > ... > > REAL :: obj(ngauge) > > [and a bunch of others] > > They should be ok, but they are dynamically allocated. (Well, Giles > claims that the term "dynamic" doesn't apply to automatic arrays, but I > disagree with him.) Regardless of what terminology one thinks > appropriate, they are allocated and deallocated during execution. > However, they aren't prime candidates for memory leaks. > > The stuff you were uncertain about, PARAMETER and DATA statements, are > completely implausible as having anything to do with memory leaks. I'm > afraid that it isn't very useful to study parts of the code that aren't > where the problem is. > > You are violating rule number 1 of asking for debugging help, namely.. > > Show the actual data rather than your deductions, guesses, and > descriptions. There is basically no data here for anyone to do anything > useful with. > > You are far from alone in this failing. It is a very common failing in > asking for debugging help. That's part of why it is rule number 1. > > -- > Richard Maine | Good judgement comes from experience; > email: last name at domain . net | experience comes from bad judgement. > domain: summertriangle | -- Mark Twain Thanks Richard - would you suggest posting my whole program? i guess that way it can be scanned for potential problems? cheers Julian |