Allocated UDT submember data lost when function called

[Reynolds__John]

I have a user-defined type that contains an allocated array of user-defined types. They're defined in this module:

module M_ArgCF
use M_kind
use m_shared_constant_definitions, only: len_name16
type tArgUDF
 integer(4) :: Kind
 integer(4)  :: Ndim=0
 integer(4),allocatable ::  intArray(:)
 real(real_kind) :: RealScalar
 real(real_kind), allocatable ::  RealArray(:)
 character(len_name16) :: Description
 character(len_name16),allocatable :: Element(:)
end type tArgUDF

type tUDFArguments
  integer(4) :: NArgs=0
   type(tArgUDF), allocatable :: Arguments(:)
end type tUDFArguments
End Module M_ArgCF

I don't think I can create a working reproduction of the error I'm about to describe, but I'll try.  For now, I'll just describe what's happening:

1) Using a TUdfArguments type, I allocate a set number of TArgUDF types.

2) I iterate through each Argument in %Arguments(:), and allocate %RealArray and %Element.

3) I call a function that's defined in a module, passing the UDFArguments variable.

4) Inside that function, the UDFArguments variable contains all of the data I passed.  Each node in %Arguments(:) is also correctly filled out, except that the %RealArray and $Element variables are no longer valid arrays and cannot be accessed without a runtime error.  Using the call stack, I'm able to see before the call and inside the function, and this bizarre behavior is actually happening.

Any ideas?

[IanH]

Sounds like the relevant dummy argument of the function is INTENT(OUT).

[Reynolds__John]

I tried it with intent(in), intent(inout) and even by value.  It's an argument that's being passed in, so intent(out) isn't appropriate. Anyway, nothing I did affected the problem.

[Reynolds__John]

I'm attaching a project that reproduces this issue. Now I'm finding it's a behavior in the debugger only. I'm still able to write the data in the "unallocated array" to the console.

[IanH]

I find that the debugger often gets confused about allocatable components, depending on ifort version, visual studio version, source arrangement, active call stack, phase of the moon, etc.  The debugger can still assist you in tracking down a problem, but it should not be your only source of truth.  In code checks, such as those provided by /check:all or by your own debugging diagnostics (write statements and the like), are generally reliable.

But a debugger telling fibs is quite a different problem from a runtime error.