A simple test: ! Test program main implicit none type :: type1 real, allocatable :: anum(:) end type type1 type :: type2 type(type1) :: temp end type type2 type(type1) :: uKnot type(type2) :: a uKnot = type1([real :: 0,0,0,1,2,3,4,4,5,5,5]) a = type2(uKnot) end which leads to: *** Error in `./a.out': double free or corruption (fasttop): 0x000000000184bf90 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7fce37214a46] ./a.out[0x400a5a] ./a.out[0x400aa0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fce371b5ea5] ./a.out[0x400699] ======= Memory map: ======== 00400000-00401000 r-xp 00000000 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 00600000-00601000 r--p 00000000 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 00601000-00602000 rw-p 00001000 08:06 792386 /home/taosong/Dropbox/[Tao]Codes/MyFortran/Try/a.out 01849000-0186a000 rw-p 00000000 00:00 0 [heap] 7fce36a3d000-7fce36a52000 r-xp 00000000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36a52000-7fce36c51000 ---p 00015000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c51000-7fce36c52000 r--p 00014000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c52000-7fce36c53000 rw-p 00015000 08:06 1310725 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fce36c53000-7fce36d56000 r-xp 00000000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36d56000-7fce36f56000 ---p 00103000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f56000-7fce36f57000 r--p 00103000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f57000-7fce36f58000 rw-p 00104000 08:06 1314626 /lib/x86_64-linux-gnu/libm-2.17.so 7fce36f58000-7fce36f93000 r-xp 00000000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce36f93000-7fce37192000 ---p 0003b000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37192000-7fce37193000 r--p 0003a000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37193000-7fce37194000 rw-p 0003b000 08:06 1057181 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 7fce37194000-7fce37352000 r-xp 00000000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37352000-7fce37551000 ---p 001be000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37551000-7fce37555000 r--p 001bd000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37555000-7fce37557000 rw-p 001c1000 08:06 1314578 /lib/x86_64-linux-gnu/libc-2.17.so 7fce37557000-7fce3755c000 rw-p 00000000 00:00 0 7fce3755c000-7fce37671000 r-xp 00000000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37671000-7fce37871000 ---p 00115000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37871000-7fce37872000 r--p 00115000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37872000-7fce37874000 rw-p 00116000 08:06 1048919 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 7fce37874000-7fce37897000 r-xp 00000000 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fce37a77000-7fce37a7b000 rw-p 00000000 00:00 0 7fce37a93000-7fce37a96000 rw-p 00000000 00:00 0 7fce37a96000-7fce37a97000 r--p 00022000 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fce37a97000-7fce37a99000 rw-p 00023000 08:06 1314554 /lib/x86_64-linux-gnu/ld-2.17.so 7fff3b3ac000-7fff3b3cd000 rw-p 00000000 00:00 0 [stack] 7fff3b3fe000-7fff3b400000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7FCE37575577 #1 0x7FCE37575B7E #2 0x7FCE371CB0AF #3 0x7FCE371CB037 #4 0x7FCE371CE697 #5 0x7FCE372085AA #6 0x7FCE37214A45 #7 0x400A59 in MAIN__ at main.f95:? Aborted (core dumped) Anyway, ifort 12.0 works well with it. Hopefully some experts can figure it out.
Confirmed. For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END BLOCK as otherwise the end-of-scope deallocation does not trigger, which causes the failure. PR57959 prevents testing whether the problem is related to the array constructor or not.
(In reply to Tobias Burnus from comment #1) > For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END > BLOCK as otherwise the end-of-scope deallocation does not trigger, which > causes the failure. Updated test case: program main implicit none type :: type1 real, allocatable :: anum(:) end type type :: type2 type(type1) :: temp end type block type(type1) :: t1 type(type2) :: t2 t1 = type1([0.,1.]) t2 = type2(t1) end block end Note: The double free goes away when changing the line t2 = type2(t1) to t2%temp = t1 That means the actual problem is not the auto-dealloc itself (which is done properly), but the construction of t2: With the second variant, a deep copy is done (allocating a separate chunk of memory for t2%temp), while in the first one t2%temp only gets a reference to the memory allocated for t1 (which is of course wrong). Since both t1 and t2 are auto-deallocated, we try to free that memory twice.
(In reply to janus from comment #2) > (In reply to Tobias Burnus from comment #1) > > For GCC 4.9, one needs to wrap the code in the main program in BLOCK/END > > BLOCK as otherwise the end-of-scope deallocation does not trigger, which > > causes the failure. > > Updated test case: > > > program main > > implicit none > > type :: type1 > real, allocatable :: anum(:) > end type > > type :: type2 > type(type1) :: temp > end type > > > block > type(type1) :: t1 > type(type2) :: t2 > > t1 = type1([0.,1.]) > t2 = type2(t1) > end block > end > > > > Note: The double free goes away when changing the line > > t2 = type2(t1) > > to > > t2%temp = t1 > > That means the actual problem is not the auto-dealloc itself (which is done > properly), but the construction of t2: With the second variant, a deep copy > is done (allocating a separate chunk of memory for t2%temp), while in the > first one t2%temp only gets a reference to the memory allocated for t1 > (which is of course wrong). Since both t1 and t2 are auto-deallocated, we > try to free that memory twice. Do you mean in fortran the default structure constructor would yield a shadow copying? Is this in the standard? Thank you. Tao Song
(In reply to janus from comment #2) > Updated test case: > That one seems to be memory-clean with current trunk. FIXED?
> That one seems to be memory-clean with current trunk. FIXED? Confirmed for gcc 5 and trunk (6.0). The test in comment 0 succeeds with 4.9.2, but not the one in comment 2 (!?). Both tests fail with 4.8.5.
> Confirmed for gcc 5 and trunk (6.0). The test in comment 0 succeeds with 4.9.2, > but not the one in comment 2 (!?). Both tests fail with 4.8.5. The first test has been fixed between revisions r199435 (2013-05-30) and r199960 (2013-06-11) and the second test between r219797 (2015-01-17) and r219823 (2015-01-18). Closing as FIXED.