From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6581 invoked by alias); 1 Oct 2009 21:22:18 -0000 Received: (qmail 6439 invoked by uid 48); 1 Oct 2009 21:21:59 -0000 Date: Thu, 01 Oct 2009 21:22:00 -0000 Message-ID: <20091001212159.6438.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00066.txt.bz2 ------- 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