DEALLOCATE dangling Fortran Pointer

Hi FTN95 Experts,

I have just completed a program where i have taken extra care to compile it properly and build it. The executable is properly created and but this error comes when I execute the executable exe file, by providing the input data file. All of the intended calculations are completed correctly.

But while completing the codes, I am deallocating each and every arrays, user defined types, pointers, but all of them are single-dimensioned arrays '(x)'..

While deallocating time, it is throwing the following error.

Runtime error from program:d:\a02\c03\proj01\fdlfsoln\fdlfproj\fdlfproj\checkmate\win32\fdlfproj.exe Run-time Error Error: Attempt to DEALLOCATE dangling Fortran POINTER

MAIN - in file 01_symmatmain.f95 at line 900 [+0be4]

but my code part looks as given below here during the 900th line: The BS is an array here.

DEALLOCATE (ITAG)
DEALLOCATE (LNXT)
DEALLOCATE (CE)
DEALLOCATE (BS2)
DALLOCATE (BS1)
DEALLOCATE (BS)   !this is the 900th line.
DEALLOCATE (LIN)
DEALLOCATE (LIN1)
DEALLOCATE (LIN2)
DEALLOCATE (TRFR)
DEALLOCATE (TRFR1)
DEALLOCATE (TRFR2)
DEALLOCATE (hdr)
deallocate (HDR2)
DEALLOCATE (genp)

I have even tried using /CHECK /UNDEF options for compiler, but no help.

Pls. advise, how to overcome this error. PS: I am using V8.10, Win8.1

Thanks

Line 900 in your code is the offending statement. Either you can't deallocate the item on that line or you have already deallocated it.

You can neither allocate nor deallocate a user-defined type but you can allocate and deallocate a variable or array with a user-defined type.

This was perfect example of not so user-friendly diagnostics of all fortran compilers I'm permanently talking about. Time to program user experience into explanatory diagnostics and teaching users how to use fortran the best!

My suggestion with this exact message to start the database which will collect interpretation of error messages and give suggestions how to proceed. Let's call it VPL. For Virtual Paul Laidler. Or VJC Or VM4 and so on.

Anyone wants to start and support it? Your name will live virtually forever

FTN95.CHM has an interesting section named 'Execution errors and IOSTAT values', in which I learned that IOSTAT in FTN95 refers (where appropriate) to Fortran runtime error numbers. That's helpful. What isn't so helpful is that the explanations are cryptic in the extreme, and a number of them are obsolete, referring to things formerly and only available in FTN77-with-DBOS.

The list includes Fortran runtime errors that are nothing to do with I/O, so therefore wouldn't return an IOSTAT value - good - but certainly the error:

Error: Attempt to DEALLOCATE dangling Fortran POINTER

isn't listed, nor some (all) of the Clearwin+ errors.

It would be useful to have an up-to-date list, even though the existing list has 193 items (from -1 to 191 including 0), to make even a start on Dan's suggestion.

Eddie

Thanks John,

I also have the same question like you.

While going through the list of ISTAT error message list, I think, it is prepared specific to FTN95. However, it might grow also in future.

We should have the standardized Error Message across all Other implementation, as Common Program Error Message Libraries, which all the external rest of the compilers are following..

The error report may be cryptic but it means that whatever is on line 900 can't be deallocated. A review of the item on this line should give the reason. Is it something that can't be deallocated? or maybe it's already been deallocated or maybe it can't be deallocated in this context.

Quoted from PaulLaidler The error report may be cryptic but it means that whatever is on line 900 can't be deallocated. A review of the item on this line should give the reason. Is it something that can't be deallocated? or maybe it's already been deallocated or maybe it can't be deallocated in this context.

The line 900 shows the array 'BS' is in allocated state here. It can be easily deallocated here using this command. Upto line 899, all were deallocated successfully, which are also the similar case. Since the control is stopped at line 900, further down lines 901 onwards were not processed.

These are the closing commands of the Program Main, hence no further processing or needs of these arrays.

Hope this helps to understand better.

Moorthy

Try commenting out this line to see if the following lines are OK.

Where is this array allocated? Is it correct to deallocate at this point?

I am guessing that you are using /CHECK. What happens without it?

Maybe there is a potential bug in FTN95/salflibc.dll. If so then we would need a short working sample in order to fix it.

Paul,

I don't think Moorthy's message is at all cryptic, but the comment was directed at some of the other the 193 messages (and the ones not listed). What about:

39 Illegal window ... or

40 No more windows available

whereas

21 Zero raised to negative or zero power

(for example) is very straightforward. This one should cause panic (although not at all cryptic):

117 Disk full

and if you want to be really puzzled if you don't remember FTN77/DBOS, how about:

120 Reference to non-existent Weitek coprocessor.

121 Too many registered traps

What does this mean:

191 Key name expected ?

And frankly, seeing that there is an error message relating to ENCODE/DECODE, I did wonder why 2 were needed:

87 ENCODE/DECODE character count zero or negative 150 Count for ENCODE/DECODE must be in the range 1 to 32767

The point was to do something helpful without adding to the workload at HQ, but ideally to start from a complete and up to date list.

Eddie

Quoted from John-Silver

I assume this means that different compilers can have different IOSTAT numbers corresponfing to a paricular message !!! Not very standardised then is it ?

I assume there's a standardised list of error messages which all compilers try to adhere to on the whole ?

There are many details that the standard does not specify at all, and there are those, such as IOSTAT, on which the standard imposes only slight restrictions. There are many errors that, according to the standard, are the programmer's responsibility to detect and rectify. A compiler is welcome to flag these errors; it is not required to do so.

There has never been a standardised list of error messages in Fortran, nor is there likely to be one in the future. What is the standard pronunciation of 'Kiribati'?

Who cares about Kiribati. I want to know the pronunciation of WINIO@ !

Whinney-Oh-At ?

Eddie

Quoted from mecej4 A compiler is welcome to flag these errors; it is not required to do so.

Long ago, I wrote a F77 routine to test if a string was a number by reading from the string and using iostat= to determine if it was an acceptable number format. I was asked to transfer this program to an IBM 'mainframe' which had terminal access. The IBM Fortran did not include 'Format data mismatch' in the list of errors it reported for an internal read. It did not return a non-zero value for iostat but crashed. I looked in the F77 standard and read that IOSTAT values are 'processor dependent' and sure enough, IBM was on the committee. I could not believe that the standard would allow this response. Not a lot of Fortran user input then, like now.

The rules of the game were different in those times. An institution bought or leased a mainframe with the intention of using it for about a decade or more, and the software was whatever the computer maker provided. Portability was not of much concern, since there was only one mainframe that was accessible at your university, large laboratory or company.

The language was simpler, too, but quite hard to debug since it had little support for structured programming.

Paul Sorry for the delayed response. But I am seeing here the good discussions by our experts, Thanks to all of them and they are very supportive to strengthen FTN95.
Pls. find my answers below on the dangling Fortran pointer. I have checked as you said. Below are my observations.

Quoted from PaulLaidler Moorthy

1. Try commenting out this line to see if the following lines are OK.
2. Where is this array allocated? Is it correct to deallocate at this point?
3. I am guessing that you are using /CHECK. What happens without it?
4. Maybe there is a potential bug in FTN95/salflibc.dll. If so then we would need a short working sample in order to fix it.

Please read below '[xxx]' as button displayed with 'xxx'.

1. I have commented all the DEALLOCATE statements. There are 4 arrays (BS,LIN,TRFR,HDR), where it is failing to deallocate, but it showed the following error message first and then if you continue further, it was showing the 2nd error message. This I have tested during DEBUG mode of running the code.

Error Message 1: System Exception 0x40010008: Format Message Failed [Break] [Continue] (On clicking Continue Button, Error Message 2 displayed below)

Error Message 2: Error: Attempt to DEALLOCATE dangling Fortran POINTER [Break] [Continue] It is then showing salflibc.dll error page saying the PDB does not exist.. etc.

2. Yes. I am using /CHECK option while compiling and getting the above Errors. If I complile without /CHECK, I get the following RunTime Error message directly

Error Message 3:

Run-time Error: Error: Attempt to DEALLOCATE dangling Fortran POINTER main - in file 01_symmatmain.f95 at line 900 [+0be4] [SaveAs] [Details] [Close]

3. For the 2 above, I got the above 'Error Message 3', while executing the EXE file. In all these cases, compiling and building executable were done successfully.

While on this, as mentioned above, there are 4 arrays, which are unallocatable, are also allocated in the MODULE itself as 'ALLOCATABLE'. Pls. see the syntax used in Module.

module  SYMMATRIXGLOBALMASTER
TYPE (BUS), DIMENSION (:), allocatable,target :: BS, BS1, BS2
TYPE (LINE), DIMENSION (:), allocatable,target :: LIN, LIN1, LIN2
TYPE (TRAFO), DIMENSION (:), allocatable,target :: TRFR, TRFR1, TRFR2
TYPE (HEADER), DIMENSION(:), allocatable,target :: HDR,HDR2 
contains
.....
end module SYMMATRIXGLOBALMASTER

In the above, as I said, there are 4 arrays which are UNALLOCATABLE: BS, LIN, TRFR and HDR. While on this, the remaining arrays were successfully unallocated. But these 4 arrays are the culprits. Hence, these issues of 'DEALLOCATE Dangling FORTRAN POINTER' error has occured. But if you closely examine each of the TYPE statements, there are 3 arrays, out of which first one is the culprit, while the rest of the arrays are deallocated. In all these 4 user types, the same trend is followed. Can you make out, anything in common from FTN95 perspectives.?

4. I can provide a sample code from this one, by extracting a smaller code out of my bigger program, which I will prepare and send it separately. In the meantime, an another sample given by mecej4 in another thread on the same subject, is also useful to showcase this error. Pls. refer to this link http://forums.silverfrost.com/posting.php?mode=quote&p=23939

I am reproducing the same example here below: (Thanks to mecej4) But I am unable to paste the code here, due to site word limitations. Please refer to the link given above.

Moorthy

I am not able to comment on the details here but you may find that you can do all that you want by using ALLOCATABLE rather that POINTER and then omit '=>NULL()'.

Paul, Yes. but still these 4 arrays only, BS, LIN, TRFR and HDR are not getting deallocated. Why it is so. No Pointers are still in allocated state, rather. As the same array types are deallocated, then, the rest of the similar type of arrays, have to be deallocated. But why it is not happening. Let me understand a bit more.

But I find the similarities that one array in each type are strongly rooted here, which can not be deallocated.. This is not the standard practice, hence want to investigate.

Moorthy

Can you provide a short sample program to illustrate this?

Quoted from narayanamoorthy_k Paul, Yes. but still these 4 arrays only, BS, LIN, TRFR and HDR are not getting deallocated. Why it is so. No Pointers are still in allocated state, rather. As the same array types are deallocated, then, the rest of the similar type of arrays, have to be deallocated. But why it is not happening. Let me understand a bit more.

But I find the similarities that one array in each type are strongly rooted here, which can not be deallocated.. This is not the standard practice, hence want to investigate.

You are welcome to investigate, but it is impossible for us to assist you with doing so because all that you have shown us so far are a number of ALLOCATE and DEALLOCATE statements. You really need to provide a complete test program to demonstrate/establish the problem.

Paul, mecej4,

Absolutely, Agreed. First-of-all, my program is with 5000 lines of code, so I am extracting the codes which reproduce this error to demonstrate to you. I will prepare and share it to you to further check..

Secondly, I am not trying to investigate for the benefit of my own, but, rather to improve our FTN95 compiler strengths. Its a bit contribution from my side too to Silverfrost.

Interesting is that I just got another dangling error 'Reference through dangling Fortran POINTER' using 32bit compiler. I knew when I was getting this error that there was not enough RAM for the arrays as there was no any pointer used in this place. But when got this for the first time I remember I lost a day or two searching what was the problem.

As to reporting errors - there would be great if everyone reported all the problems they get as well as any suggestions. Here is lifetime experience: no matter which topic it is, even the shortage of electric power in the area affective thousands of houses, only 1 off 100 people or more bother to report, others get shy or wait for others to do that. No matter what the country in the world, I was first around 3 times calling electric shortages around 10pm returning to dark home, people in the entire region were sitting for few hours in the darkness waiting who the hell will call first 😃. Only when there is fire people report quick, in 2 out of also 3 cases when there was a fire nearby I was not the first to call.

Meantime the programming bugs sometimes could be very tricky taking days and weeks to search (twice I hunted bug for a month, and couple too devious bugs I still can not find for more then decade, they are not in the often used parts of the code or workarounds are used instead. Sharing experience and best practice with the Clearwin+ GUI is also important).