DEALLOCATE PROBLEM

[nvaneck]

In the following code, all arrays are allocated at the time of the first IF test. After the DEALLOCATE in that IF statement, all but the 3 arrays in the following IF tests are in fact deallocated, but K is #CCCCCCCC. After the subsequent IF tests, the remaining 3 arrays are deallocated and k=0 each time. Is this a bug in release 9 of the compiler I am using, or is something going on that I don't understand?

IF (ALLOCATED(A_CON)) DEALLOCATE(A_CON,A_ATAB,A_LTAB,A_RNAME,A_CARRY,A_LOGI,A_TI,A_RVAR,STAT=K)

IF (ALLOCATED(A_RVAR)) DEALLOCATE(A_RVAR,STAT=K)

IF (ALLOCATED(A_RNAME)) DEALLOCATE(A_RNAME,STAT=K)

IF (ALLOCATED(A_CARRY)) DEALLOCATE(A_CARRY,STAT=K)

Thanks,
Neal

[mecej4]

What are the allocation statuses of the variables A_CON, A_ATAB, A_LTAB, A_RNAME, A_CARRY, A_LOGI, A_TI and A_RVAR before the statements that you showed?

[Steven_L_Intel1]

Can you provide a complete example that demonstrates this? What happens if you use a current compiler?

[nvaneck]

They are all allocated before the statements. All but the three in the three separate IF statements are undefined after the 1st deallocate statement, all are undefined at the end of all the statements.

Actually, the compiler is 10.1.013, and it is the latest verison I have.)

I can get around it the way it's written, so it's not holding me up, but is worrisome because I have a lot of allocations in the project and similar deallocations. Before I ran into this problem I had recoded a lot of separate deallocations last year, not realizing it might not be a logic problem at the time. I'm not sure I can get a concise executable example as this is a complex project.

[mecej4]

If you will make up a small but complete example to demonstrate the problem, i.e., a 'reproducer', it should be easy to try out a later version of the compiler.

That would involve less effort than to create from scratch a test program to show up errors in an older version of the compiler.

[nvaneck]

Unfortunately, I can't get it to fail anymore as I've lost how I got it to fail while I worked on other problems. I did find some related things to fix, so it presumably it is a problem of my own making which I've now gotten around.

Thanks for all the responses.

[nvaneck]

Well, I spoke too soon; it's back. I had found an area where the deallocation was supposed to take place, but apparently didn't. This is what led me to add the example above at the place of original allocation to check for it, but the same problem occurs anyway after matching the deallocations with the allocation statement.

I need to do some more investigating.

[Jugoslav_Dujic]

You are possibly hiding the problem by including stat=K. I would remove it first, and let the program fail however it was supposed to fail. In addition, I would split the DEALLOCATE statement into several, to see which one exactly fails. My guess is that you have a silent memory corruption somewhere, which causes the deallocation to fail.

[jimdempseyatthecove]

Neal,

In addition to the prior advice, add

K=0

prior to the DEALLOCATE(..., STAT=K)

In one of the versions of IVF, K would be set on error, or left as-is on no error.

If that doesn't lead you some where, then follow Jugoslav's advice
Do not assume the arrays following A_CON on the first DEALLOCATE have been, or still are, allocated.
Insert diagnostic code to test, then recode to do each individualy.

Note, a programming error (e.g. array subscript out of bounds) could clobber an array descriptor. If the deallocation (when array appears allocated) produces an error, then assume the arry descriptor got clobbered (or was junk to begin with).

Are any of these array descriptors in thread private memory?
If so, I had problems with earlier versions of IVF with array descriptors in thread private memory. Array pointers were OK. (remember to change/add IF(ALLOCATED... to IF(ASSOCIATED...

Jim Dempsey

[nvaneck]

Thanks for all the good advice.

I put in stat=k after the problem arose, andI had checked each to see if anywere undefined,to see if it reported a problem. I separated the items to isolate the problem, which was with thelatter three. I tested each in debug to see which was still allocated before and after each statement.

That said, the problem is solved. I found that I had tested the latter 3 for allocation, deallocatedthem as needed before allocation, in a different routine. I moved all deallocation to a global close routine where other deallocations occur(these werein an I/O routine)and eliminated the test and deallocation of the 3 from the other routine and it now works repeatedly as needed.

I don't know why the behavior occurred as in the example, i.e., why wouldthe first deallocationfail to dfeallocate the problem 3 and then work in the subsequent deallocates, but the problem is gone now and the code is better. Perhaps something did get clobbered somewhere.

None were in thread private memory, and bounds checking was on for all arrays.

Neal Van Eck