forums.silverfrost.com

[Anonymous]

I am encountering various problems in relation to derived types
Here is the shortest test case I can produce:
[pre]
module my_string

type string
private
character, pointer:: chars( => null()
end type

interface assignment (=)
module procedure s_ass_c
end interface

private s_ass_c

contains
elemental subroutine s_ass_c(var,expr)
type(string) , intent(out) :: var
character(len=*), intent(in) :: expr
integer :: lc,i

lc = len(expr)

if(associated(var%chars))deallocate(var%chars)
allocate(var%chars(1:lc))
do i = 1,lc
var%chars(i) = expr(i:i)
enddo
end subroutine s_ass_c

end module my_string

module my_mod
use my_string
type my_type
type(string) :: buf
end type

type my_other_type
type(my_type),dimension(1:10) :: buf_arr
end type

end module my_mod

program test
use my_mod

type(my_type) :: t
type(my_type) :: t_arr(1:2)
type(my_other_type) :: t_other

t%buf = "Works"

t_arr(1)%buf = "Works too!"

t_other%buf_arr(1)%buf = "Works not!"

end program[/pre]

This program crashes when trying to execute the line in bold. Actually the crash takes place in the assignement procedure, where the

[Anonymous]

Have you tried compiling with /undef? It should produce a more meaningful message.

[Anonymous]

I just tried it, the message does not change a lot.

[pre]
Runtime error from program:d:devbugslgotemp@.exe
Access Violation
The instruction at address 0362376e attempted to read from location 8080807c

036236ff __DEALLOCATE [+006f]

036ef5a6 __PFREE [+01b2]

MY_STRING!S_ASS_C - in file derived_type_1.f90 at line 22 [+004e]

TEST - in file derived_type_1.f90 at line 54 [+00fe]


eax=0a0a0000 ebx=00003188 ecx=0000000a
edx=0a0a0010 esi=0360fbb4 edi=80808080
ebp=0360faec esp=0360fac8 IOPL=2
ds=0023 es=0023 fs=003b
gs=0000 cs=001b ss=0023
flgs=00010282 [NC OP NZ NS DN NV]

0362376e cmp [edi-0x4],0xabcdef12
03623775 jne 3623781
0362377b add edi,0xfc
[/pre]

[Anonymous]

Jonny

Looks like you have found a bug here.
The initialisation (=> null() ) has not been applied in the last case so the deallocate causes a runtime exception.

A work-around is to explicitly nullify with a call to nullify(t_other%buf_arr(1)%buf%chars) before the assignment (i.e. before the first time this particular variable is used).

[Anonymous]

Paul,
thanks for replying quickly.

The workaround works, however as the chars component is private to the string type, and also because a test for ASSOCIATED is done in other parts of the strings module, what I will have to do is never test for association and always allocate a new target. This of course will leak memory.

While experimenting with this I stumbled over another compiler problem. I'll open a new thread for it

Johny

[PaulLaidler]

Jonny

I think that we will be able to fix the bug before long but probably not before the next release.
In the meantime you could consider adding an extra field to the TYPE to indicate the allocated state.

[PaulLaidler]

Johny

This bug has now been fixed and the fix will be included in the next release.

[Johny]

Paul,

thank you for the reply.
I will eagerly wait for the next release, as the workaround proposed earlier does not work either. Any component in the derived type does not get properly initialized.

[JohnyBergmann]

Hello,

with the release 4.90, the above code now works correctly



Johny