Run-time error in Fortran 2003 code: glibc detected free(): invalid next size (fast)

[Sean_S_2]

I've had some issues trying to make some Fortran tests work (they use pFUnit, which requires most of Fortran 2003 to be implemented). It's rather difficult to reduce the test cases, partly because I get a lot of different symptoms (e.g. segfaults, hanging), and partly because there is generated code in the unit test framework, which is hard to modify by hand without causing problems.

Anyway, I've been trying to figure out whether there are bugs in ifort 14.0 that are contributing to this. I mocked up a case that has some similarities to the code I'm trying to debug, and managed to find an error in the handling of an allocatable.

module foo_bar_types

implicit none

type :: array_type
   integer, allocatable :: array(:)
end type array_type

abstract interface
   type(array_type) function get_array_wrapper()
     import :: array_type
   end function get_array_wrapper
end interface

type :: foo
   procedure(get_array_wrapper), pointer, nopass :: getter => null()
end type foo

end module foo_bar_types

program test_polymorphic_allocation

use foo_bar_types

implicit none

type(foo) :: bar_source
class(foo), allocatable :: bar_poly

integer :: i

allocate(bar_poly, source=bar_source)
deallocate(bar_poly)

end program test_polymorphic_allocation

I guess the first question that comes to mind is, have I done something wrong, or does this look like a potential bug in ifort? This test case is maximally reduced and bizarrely specific. The error goes away if:

• foo is defined in the program instead of a separate module.
• bar_poly is changed to not be polymorphic.
• foo does not contain the specific component it does, namely:
  • A pointer to a procedure,
  • that returns a derived type,
  • with an allocatable, array component.

If you remove the "deallocate" statement from the test case, then the error goes away, but valgrind still finds an issue with the allocate statement.

[Sean_S_2]

After looking at this a bit longer, I'm fairly confident that this is a bug in ifort...

[Izaak_Beekman]

I see nothing wrong with your code and would be inclined to agree that this is a defect in the compiler. Oddly, on OS X (mavericks) and ifort 13.0.2 20130314 I get no compile time or run time errors if I compile your code without any flags to ifort, nor does instruments leak check find any leaks. (Memcheck is still very experimental on OS X AFAICT)

[Steven_L_Intel1]

I think the compiler is mishandling the allocate with source=. I think this is an issue we're already working but I will check.

[FortranFan]

FWIW, the code snippet in the original post compiles and executes without any issues using gfortran 4.9.

Don't know if this is of any help: on the Windows platform with the "Release" configuration (i.e., optimizations turned on) the code compiles and executes fine using Intel Fortran XE 2013, Update 1; it is only the "Debug" configuration that raises a run-time error from the Microsoft C run-time library with heap corruption.  On Linux, the behavior may be different.  But I hope the eventual fix in Intel Fortran will resolve the run-time issue on Windows as well.

[Steven_L_Intel1]

While the program may execute without errors, that doesn't mean it is doing it correctly. The type of error is one the program may or may not have an issue with.

[FortranFan]

Steve Lionel (Intel) wrote:

While the program may execute without errors, that doesn't mean it is doing it correctly. The type of error is one the program may or may not have an issue with.

Steve,

Thanks, appreciate your comments.  Note my interest is in sourced allocation (and also, "molded" allocation) involving polymorphic types using Intel Fortran, albeit on the Windows platform.  That's something I've been using extensively in my code.  Since the OP was mainly raising the issue about run-time error during sourced allocation, I was just curious how my Windows version of the compiler would respond to the same code.  When it failed with a C run-time library exception in Debug configuration, it seemed like something that might be worth looking into for the benefit of Windows users of Intel Fortran, regardless of the Release configuration result.  By the way, on the Release version runs (tried 3 different settings: /O1, O2, and /O3), I did keep an eye on the SysInternals Process Explorer utility before, during, and after execution for memory leaks, etc. but didn't notice anything amiss.

That reminds me: would Intel Inspector (or is it VTune Analyzer) correctly inform the user of any memory issues with Fortran 2003 and 2008 features such as sourced (and MOLD=) allocation?

[Steven_L_Intel1]

Inspector XE does complain about this program.

[Steven_L_Intel1]

Escalated as issue DPD200256204.  The error also goes away if one uses MOLD= instead of SOURCE= for the allocate.

[Steven_L_Intel1 · Accepted solution]

This has been fixed for the 15.0 release later this year.