我写了一个fortran代码,它以一种我不理解的方式失败了。我已经尝试在下面清楚地解释了这个场景,但如果不清楚,请要求我澄清。
该代码包括一个子例程
SUBROUTINE TMGP(NSYM,NOB,NFT,DEN,ncod,PR,np,lden,NPMX,nuccen,mdel)
IMPLICIT NONE
...
INTEGER :: NINTS
REAL(KIND=wp), ALLOCATABLE :: XBUF(:)
...
print *,"xbuf allocated ?",allocated(xbuf)
print *,"xbuf not allocated ?",.not.allocated(xbuf)
if (allocated(xbuf)) then
DEALLOCATE(xbuf)
end if
if (.not.allocated(xbuf)) then
allocate (xbuf(nints))
end if
...
RETURN
END SUBROUTINE TMGP
但是,当我运行这个程序时,它在以下代码行上失败:
DEALLOCATE(xbuf)
带着错误
forrtl: severe (173): A pointer passed to DEALLOCATE points to an array that cannot be deallocated
输出如下:
xbuf allocated ? T
xbuf not allocated ? F
如果我将代码更改为(除了添加下面这行代码外,不做任何其他更改):
print *,"xbuf allocated ?",allocated(xbuf)
print *,"xbuf not allocated ?",.not.allocated(xbuf)
print *,"nints = ",nints
if (allocated(xbuf)) then
DEALLOCATE(xbuf)
end if
if (.not.allocated(xbuf)) then
allocate (xbuf(nints))
end if
然后运行这个程序,它会在以下代码行中失败:
allocate (xbuf(nints))
我得到了这样的信息:
forrtl: severe (151): allocatable array is already allocated
输出如下:
xbuf allocated ? F
xbuf not allocated ? T
nints = 1
我对此非常困惑,因为在我看来,我使用的if语句应该会使这种问题变得不可能,并且按照代码的逻辑,这些错误应该是不可能的。
我正在使用ifort编译器,任何可能导致这个问题的想法或如何修复它的建议都将非常感谢。
如果有任何额外的信息,请让我知道。
詹姆斯
发布于 2015-05-07 07:17:00
您的观察结果可能是内部描述符损坏的结果,编译器使用该内部描述符跟踪可分配(或指针)对象的状态,与特定编译器存储和测试对象的分配状态的方式交互。
这是特定编译器的许多实现细节,但至少有两种方式将对象的“已分配”状态存储在对象的描述符中-为支持对象的实际数据提供非空机器地址,以及在描述符中设置单独的标志。ALLOCATE内部函数正在查看其中一条信息,而ALLOCATE语句的运行时支持正在查看另一条信息。通常这两条信息是一致的,但在面对内存损坏时,您会看到明显的矛盾。有关当前版本英特尔Fortran描述符布局的文档,请访问https://software.intel.com/en-us/node/525356。
(另一个标志跟踪描述符是用于可以释放的内容(即,它是通过分配或类似方式创建的内容)还是不是(可能描述符是用于引用另一个数组的一部分的指针)-该标志的损坏会导致"...数组无法被释放“消息。)
内存损坏可能是由程序中的错误引起的,该错误可能不在数组声明和使用的直接源位置。正如其他人在注释中建议的那样-去寻找代码中的编程错误,例如数组下标越界或参数列表中的不匹配。编译器的运行时诊断选项通常会有所帮助。通过适当的调试能力,您还可以监视相关数组描述符的内存存储,并准确地确定描述符的状态首次出现不一致的时间。
https://stackoverflow.com/questions/30079746
复制相似问题