------- Comment #8 from burnus at gcc dot gnu dot org 2009-10-01 21:21 -------
Minimal test case:
program main
type :: container_t
integer, allocatable :: entry
end type container_t
type(container_t), dimension(1) :: a1, a2
allocate (a1(1)%entry, a2(1)%entry)
a2(1)%entry = 1
a1(1:1) = pack (a2(1:1), mask = [.true.])
end program main
I think what happens is the following: In pack one copies (memcpy) the bytes
from A2 to A1 - that whay A1 is a one-to-one copy of A2. At the end automatic
deallocation happens. First one frees (and nullifies) A1. Then one moves on to
A2, which is an exact copy of A1; thus A2%entry points to the same memory as
A1%entry - but the memory was already freed.
Thus we are obviously mishandling derived types with allocatable (or pointer)
components. Adding "print *, loc()" before and after pack illustrates this:
6307888 ! loc(a2(1)%entry - before pack
6307856 ! loc(a1(1)%entry - before pack
6307888 ! loc(a2(1)%entry - after pack
6307888 ! loc(a1(1)%entry - after pack
Actually, ifort shows the same result:
7020672
7020640
7020672
7020672
(and openf95 and pathf95 crash in pack).
While both NAG 95, sunf95 and g95 seem to handle it correctly:
6722520
6722456
6722520
6722456
That those handle it correctly, can also be seen if one adds:
a1(1)%entry = 2
print *, a2(1)%entry, a1(1)%entry
It should print "1 2" (as with NAG f95, g95 and sunf95) but gfortran and ifort
print "2 2".
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|function "pack" causes |Corrupted memory using PACK
|double free violation |for derived-types with
| |allocated components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
