|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Feb 12, 2018 3:10 pm Post subject: |
|
|
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()". |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Tue Feb 13, 2018 7:11 am Post subject: |
|
|
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. _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Feb 13, 2018 10:15 am Post subject: |
|
|
Moorthy
Can you provide a short sample program to illustrate this? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Feb 13, 2018 1:34 pm Post subject: Re: |
|
|
narayanamoorthy_k wrote: | 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. |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Wed Feb 14, 2018 7:43 am Post subject: |
|
|
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. _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Wed Feb 14, 2018 12:10 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Feb 14, 2018 1:11 pm Post subject: Re: |
|
|
narayanamoorthy_k wrote: | 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. |
The shorter, the better, but a 5000 line program is not unmanageable if it is complete and can be compiled and run to exhibit the problem.
Quote: | Secondly, I am not trying to investigate for the benefit of my own, but, rather to improve our FTN95 compiler strengths. |
We all benefit whenever a bug is reported in sufficient detail regarding the circumstances in which it surfaces. The reporting is a prerequisite to countermeasures being taken, whether by the compiler vendor (creating bug fixes to be put in place by the next release) or by users (placing checks and safeguards in their code to circumvent the bug, if possible). |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Wed Feb 14, 2018 1:46 pm Post subject: |
|
|
Ok. Sure mecej4. I am planning a very shorter code to demonstrate this issue. _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
|
|
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
|