Bug 57957 - [F03] Double free with allocatable components
Summary: [F03] Double free with allocatable components
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.1
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2013-07-23 00:54 UTC by Tao Song
Modified: 2015-10-21 00:19 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.5.3, 4.8.1, 4.9.0
Last reconfirmed: 2013-07-23 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tao Song 2013-07-23 00:54:35 UTC 
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.
Comment 1 Tobias Burnus 2013-07-23 08:02:41 UTC 
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.
Comment 2 janus 2013-08-21 12:14:44 UTC 
(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.
Comment 3 Tao Song 2013-10-25 20:31:24 UTC 
(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
Comment 4 Mikael Morin 2015-04-18 09:24:39 UTC 
(In reply to janus from comment #2)
> Updated test case:
> 
That one seems to be memory-clean with current trunk.  FIXED?
Comment 5 Dominique d'Humieres 2015-04-18 09:50:14 UTC 
> 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.
Comment 6 Dominique d'Humieres 2015-10-21 00:19:57 UTC 
> 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.