Showing results for 
Search instead for 
Did you mean: 
Black Belt
1 View

Intermittent access violation with extension of parameterised type

The attached example fails intermittently (it may need to be run several times to see the failure) when compiled with 17.0 update one.  I think the code is legit.

MODULE FortranLib
  TYPE, ABSTRACT, PUBLIC :: Parent(param)
    INTEGER, LEN :: param
  END TYPE Parent
  PUBLIC :: CreateExtension
  TYPE, EXTENDS(Parent) :: extension
  END TYPE extension
  SUBROUTINE CreateExtension(name, object)
    CHARACTER(*), INTENT(IN) :: name
    CLASS(Parent(:)), INTENT(OUT), ALLOCATABLE :: object
    TYPE(extension(:)), ALLOCATABLE :: tmp
    ALLOCATE(extension(3) :: tmp)
    tmp%name = name                   !<<<<<
    CALL MOVE_ALLOC(tmp, object)
  END SUBROUTINE CreateExtension

PROGRAM FortranExample
  USE FortranLib
  CLASS(Parent(:)), ALLOCATABLE :: x
  CALL CreateExtension('Fred', x)
END PROGRAM FortranExample

The symptoms of the failure, when it fails, varies - sometimes it is an access violation, sometimes a complaint about an allocatable that cannot be deallocated, sometimes the "this program stopped working" dialog box, sometimes a refusal to write any further code until someone restocks the coffee.

>ifort /check:all /warn:all /standard-semantics /Od /debug /traceback "2016-11-22 boom.f90" && "2016-11-22 boom.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2016-11-22 boom.exe"
"-pdb:2016-11-22 boom.pdb"
"2016-11-22 boom.obj"
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
2016-11-22 boom.e  00007FF70FEE2F6D  Unknown               Unknown  Unknown
2016-11-22 boom.e  00007FF70FE43625  Unknown               Unknown  Unknown
2016-11-22 boom.e  00007FF70FE414FC  FORTRANLIB_mp_CRE          27  2016-11-22 boom.f90
2016-11-22 boom.e  00007FF70FE418D7  MAIN__                     39  2016-11-22 boom.f90
2016-11-22 boom.e  00007FF70FED73DE  Unknown               Unknown  Unknown
2016-11-22 boom.e  00007FF70FED7E4D  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFD74C18364  Unknown               Unknown  Unknown
ntdll.dll          00007FFD77705E91  Unknown               Unknown  Unknown


0 Kudos
2 Replies
1 View

Thanks - we'll check it out.

Thanks - we'll check it out.

Retired 12/31/2016
0 Kudos
1 View

Escalated as issue

Escalated as issue DPD200416168. I could reproduce it in Visual Studio, even did an Inspector XE run on it, and then it started working fine. I can reproduce from the command line with reasonable consistency. My guess is that a bad address is being passed to the memory copy routine.

Retired 12/31/2016
0 Kudos