forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DEALLOCATE dangling Fortran Pointer
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Thu Feb 08, 2018 12:30 pm    Post subject: DEALLOCATE dangling Fortran Pointer Reply with quote

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.

Quote:
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.

Code:
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
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Thu Feb 08, 2018 4:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Feb 08, 2018 10:49 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Feb 09, 2018 12:29 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Feb 09, 2018 3:48 am    Post subject: Reply with quote

The on-line list can be found at:
http://silverfrost.com/ftn95-help/ex_err/execution_errors_and_iostat_values.aspx

There is a function available also to put the error message on-screen:
[quote]RUNERR@ prints an error message on the screen corresponding to a given IOSTAT value ISTAT. These are the error messages listed in Execution errors and IOSTAT values .

An interesting note in the Error numbers documentation is:
Quote:
The positive values chosen for IOSTAT in this implementation of Fortran 95 will, in all probability, differ from those chosen in any other implementation for the same error conditions


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

The question then arises is the 'dangling pointer' error message a ìn FTN95 specific one or is it on a 'standardised' list ? I assume there's a standardised list of error messages which all compilers try to adhere to on the whole ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Fri Feb 09, 2018 5:58 am    Post subject: Reply with quote

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..
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Feb 09, 2018 9:43 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Fri Feb 09, 2018 10:01 am    Post subject: Re: Reply with quote

PaulLaidler wrote:
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.
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Fri Feb 09, 2018 10:16 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Feb 09, 2018 10:43 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Feb 09, 2018 3:56 pm    Post subject: Re: Reply with quote

John-Silver wrote:

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"?
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Feb 09, 2018 5:35 pm    Post subject: Reply with quote

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

Whinney-Oh-At ?

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat Feb 10, 2018 1:42 am    Post subject: Re: Reply with quote

mecej4 wrote:
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.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sat Feb 10, 2018 4:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
narayanamoorthy_k



Joined: 19 Jun 2014
Posts: 142
Location: Chennai, IN

PostPosted: Mon Feb 12, 2018 3:02 pm    Post subject: Reply with quote

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.

PaulLaidler wrote:
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.

Code:
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.
_________________
Thanks and Regards
Moorthy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group