Funny problem with the debugger

I am debugging a program that in one of the subroutines contains the following code:

npt=size(matrix_so%x) if(allocated(org_y)) deallocate(org_y) if(allocated(kt)) deallocate(kt) if(allocated(h_kt)) deallocate(h_kt) if(allocated(S_kt)) deallocate(S_kt) if(allocated(a)) deallocate(a)
if(allocated(b)) deallocate(b)
allocate(org_y(npt)) allocate(kt(npt)) allocate(h_kt(npt)) allocate(S_kt(npt)) allocate(a(npt),b(npt))

the funny thing is that when I am debugging step by step, the debugger hangs in the statement

allocate(org_y(npt))

and I say funny because there are a lot of 'allocate' statements along the whole program and only in this subroutine the debugger crashes. What could I do in order to check why this happens? The debugger gives me no clue at all!

Agustin

Agustin,

I had a similar problem recently and did 2 things to overcome it: 1-I reduced the size of all common to less than 1gb 2-I made sure that all routines in the calling stack were compiled with /check.

The other problem might be that with /check with sdbg, memory released by DEALLOCATE is not reused. I have had problems with running out of memory and also stack overflow with sdbg and /check but it all disappears with /debug. Paul may be better able to confirm the restrictions on releasing memory.

You should check that the accumulated total memory allocation is less than about 1.6gb, otherwise you can start to have problems, especially with /check. The /3gb switch can help but this does not work with /check and sdbg. If this appears to be the problem area, you can use LOC to report the memory address of allocated arrays to a log file, to see where it is happening.

I have never been able to declare a larger stack size and overcome similar problems sucessfully, although I think ALLOCATE does not use the stack (?). I do find ALLOCATE to be more stable than automatic arrays, probably for this reason.

To overcome this possibility, can you reduce the size of the test problem to confirm the program is working ok, then test the full problem in production mode. You may still find it useful to report accumulated memory allocated to see how close to the limit you are going.

John

You are right!! The program running without /check option presents no problems at all!! I have just used only /debug and entered in the debugger at the breakpoint position I marked in Plato without problems. I think that maybe Paul has something to say about why the /check option gives some problems when using the debugger. The funny thing was (and is) that the program has several subroutines with allocate and deallocate statements and there was only one that entered in this kind of problems. So it seemed to me that the problem was not with the allocated memory but with something more strange. Well, I do not know which is actually the problem, but at least, I can run my program with the debugger for the first time in several months! (well, since I decided to include the problematic subroutine in the program.)

Thanks a lot John! Have a nice weekend..

Agustin (from a sunny but rather cold City Bell)

I can only give my general impression about this.

/check uses an old memory allocation process where a large chunk of memory is allocated initially and then distributed on demand. Returned memory is not defragmented within this large chunk. This means that reallocation of returned memory is somewhat limited.

Hmm, the debugger still should not hang - apart from anything else it is in a separate process. I don't suppose this is a form that is easy for me to reproduce?

Quoted from Robert Hmm, the debugger still should not hang - apart from anything else it is in a separate process. I don't suppose this is a form that is easy for me to reproduce?

Well, I would say that it could not be easy to reproduce, as I can run any subroutine in my program without problems using /check and /debug....except the one that hangs!. The other ones also deallocate and allocate arrays of more or less the same size, so...why this particular subroutine has a problem?. I have no expertise in compilers, stacks and etc., etc. but...could it be that the problem appears because the PS (= problematic subroutine) is always allocated (could I use this term?) in the same order or position, so that the problem appears because the subroutine is always in the same place in memory where we are beyond the allocation limit for /check? Is there any way to change this behavior? (I mean, how could I say the compiler to store first subroutine D instead of subroutine A?). I am just speaking from the position of a very ignorant person with respect to compilers, so that I could be saying very silly things.

By the way John: how can I perform a report of the accumulated memory allocated at different steps of the program? Any particular FNT95 subroutine?

Best regards,

Agustin

You can run the following program with options '/debug /lgo' and '/check /lgo' and see that each call with /check usually gets new memory, while the /debug does not. They both end with insufficient memory, but at different values of npt, giving an error I am familiar with. (My other problem failed allocating an array of only 800 bytes.) With /check, you can see that the memory is not being reused. What I have seen from other tests is there are little bits of memory taken out in a number of places over the 2gb of available memory, which can stop ALLOCATE from getting a large single chunk of memory. The order of multiple ALLOCATE statements can be important in this case.

    integer*4 npt
   do npt = 1000, 10000, 1000
   call allocate_some (npt)
   end do
   end

   subroutine allocate_some (npt)
   integer*4, allocatable, dimension(:)   :: kt
   real*8,    allocatable, dimension(:)   :: org_y, h_kt, s_kt
   real*8,    allocatable, dimension(:,:) :: a, b
!
   integer*4 npt
!
!  npt=size(matrix_so%x) 
   if (allocated(org_y)) deallocate(org_y) 
   if (allocated(kt))    deallocate(kt) 
   if (allocated(h_kt))  deallocate(h_kt) 
   if (allocated(S_kt))  deallocate(S_kt) 
   if (allocated(a))     deallocate(a) 
   if (allocated(b))     deallocate(b) 
!
   allocate (org_y(npt)) 
   allocate (kt(npt)) 
   allocate (h_kt(npt)) 
   allocate (S_kt(npt)) 
   allocate (a(npt,npt))
   allocate (b(npt,npt)) 
!
   write (*,*) ' '
   write (*,*) ' Running for npt =',npt
   call Report_allocate_8 (org_y, npt, 'org_y') 
   call Report_allocate_4 (kt,    npt, 'kt') 
   call Report_allocate_8 (h_kt,  npt, 'h_kt') 
   call Report_allocate_8 (S_kt,  npt, 's_kt') 
   call Report_allocate_8 (a,     npt*npt, 'a')
   call Report_allocate_8 (b,     npt*npt, 'b') 
!
   return
   end

   subroutine Report_allocate_8 (b, npt, array_name) 
!
   integer*4 npt, ii
   real*8 b(npt)
   character array_name*(*) 
!
   ii = loc (b)
   write (*,1001) 'Allocate at', ii, npt*8, array_name
1001 format (a,b'zz,zzz,zzz,zz#',' of ',i0,' bytes for array ',a)
   end

   subroutine Report_allocate_4 (b, npt, array_name) 
!
   integer*4 npt, ii
   integer*4 b(npt)
   character array_name*(*) 
!
   ii = loc (b)
   write (*,1001) 'Allocate at', ii, npt*4, array_name
1001 format (a,b'zz,zzz,zzz,zz#',' of ',i0,' bytes for array ',a)
   end