forums.silverfrost.com

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

Why does the text array fail to be allocated in the following code?:

MattMcD · Joined: 06 Sep 2007 Posts: 19 Location: Cambridge,UK

try using nullify(text_array) instead of deallocate
I think I had a similar problem and it worked for me!

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

I should have said that the status values are:
istat = 2
jstat = 0

Which means that the text_array has not been allocated, but the integer one has.

If I did not test the status, then an error would occur when deallocating.

Ian

PaulLaidler · Posted: Tue Apr 08, 2008 1:01 pm Post subject:

Before checking this out in detail I just want to make sure that you are not using version 5.20 of FTN95 which has a known regression concerning some uses of ALLOCATE.

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

Paul, I'm using version 5.20.1 - see listing.
salflibc.dll dated 02/03/2008 time 01:32

Regards

Ian

Silverfrost FTN95/WIN32 Ver 5.20.1 allocate.F95 Tue Apr 8 18:40:58 2008

Compiler Options in Effect:
COLOUR DELETE_OBJ_ON_ERROR LINK LIST MINIMISE_REBUILD NO_QUIT NON_STANDARD SINGLE_THREADED

0001 program allocate
0002 ichar_len = 32
0003 iarray_len = 1000
0004 call text_allocatable(ichar_len,iarray_len)
0005 end
0006
0007
0008 subroutine text_allocatable(ichar_len,iarray_len)
0009
0010 character (len=ichar_len), allocatable, dimension(:) :: text_array
0011 integer (kind=3), allocatable, dimension(:) :: isort_list
COMMENT - Specifying the kind of the type INTEGER with the constant '3' is non-portable -
'SELECTED_INT_KIND(9)' would be better
0012 print *,ichar_len,iarray_len
0013 allocate (text_array(iarray_len), stat=istat)
0014 allocate (isort_list(iarray_len), stat=jstat)
0015
0016 print *,'allocation status',istat,jstat
0017
0018 if(istat .eq. 0)then
0019 deallocate (text_array)
0020 endif
0021 if(jstat .eq. 0)then
0022 deallocate (isort_list)
0023 endif
0024
0025 end

PaulLaidler · Posted: Wed Apr 09, 2008 12:20 pm Post subject:

OK, this looks like a bug we have not seen before.
We will aim to fix this soon but the fix probably wont be available until the next major release.

PaulLaidler · Posted: Mon Jun 16, 2008 2:04 pm Post subject:

This bug has now been fixed.

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

Thanks

Ian

PS, when will the outside world see this fix?

PaulLaidler · Posted: Wed Jun 18, 2008 1:47 pm Post subject:

In the next release of FTN95 which would normally be 6 to 12 months from now.

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

Paul,

I have a similar problem in 5.21 (also appeared and reported in 5.20 & 5.20.1) where an array allocated within a subprogram is going haywire. It works in previous versions so I haven't been able to upgrade. I've tried to trim it down to a reportable size with no success so far (it's a big program).

Is there any chance I can try out the fixed version now to see if my problem has gone away ? It'll save us all a pile of time if it has.

Thanks,
Alan

PaulLaidler · Posted: Fri Jun 20, 2008 12:43 pm Post subject:

The bug is very specific to allocating memory for a character array where the character length of an element is supplied as a variable argument.

If you have exactly this situation then it will be necessary to use a work-around or to apply to Silverfrost for an intermediate build.

If you have a different problem that cannot be isolated then you can apply to Silverforst to send a zip archive of all the code for forwarding to me.

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

My problem is with a pointer-based integer array within an ADT where the length of the array is passed as an argument. Sounds like it's not the same problem but a bit too similar for comfort.

There is more info at my earlier report on the same problem at http://forums.silverfrost.com/viewtopic.php?t=1028. I'd appreciate some comment on this in case it's in some way related or rings a few bells. It is going to quite a lot of work to slim it down so any ideas would be gratefully received. Either that or stick to using v4.91.

How does one apply for an intermediate build - is it not worth trying it out ?.

Alan

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

I have been able to cut this down. The demo program can be downloaded from:
http://www.wsanoise.com/testsite/download/FTN95AllocateBug.zip

It's a full solution with various watches and a breakpoint set - the comments in the code describe the problem but basically an allocate seems to corrupt memory around it but it's highly dependent on the surrounding code. It only happens on versions 5.20 and above (incl 5.21) on XP and Vista on VS2008.

Cheers,
Alan

PaulLaidler · Posted: Sat Jun 21, 2008 8:10 am Post subject:

I have downloaded your zip archive and the "bug" still seems to be there.
Also, strangely, when I run your code through the debugger, Visual Studio gives me a serious error warning (but continues running).

We will investigate the "bug" as soon as we can.

PaulLaidler · Posted: Mon Sep 08, 2008 11:13 am Post subject:

This bug has now been fixed for the next release.