forums.silverfrost.com

aebolzan · Posted: Fri Jul 16, 2010 2:49 pm Post subject: 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

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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

aebolzan · Posted: Sat Jul 17, 2010 4:57 pm Post subject:

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)

PaulLaidler · Posted: Sun Jul 18, 2010 7:37 am Post subject:

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.

Robert · Joined: 29 Nov 2006 Posts: 457 Location: Manchester

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?

aebolzan · Posted: Sun Jul 18, 2010 11:33 pm Post subject: Re:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

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.