如何追踪潜在的不确定行为情况? [英] How do I trace a potential undefined behavior situation?

问题描述

当关联了指针时，我在释放时遇到了一个双重释放错误.我怀疑某些不确定的行为仍在继续，但是我不知道从哪里开始寻找它，或者如何寻找.您如何跟踪未定义的行为?

I get a double free error on deallocate, when the pointer is associated. I suspect some undefined behavior is ongoing, but I have no idea where to start looking for it, or how. How do you track down undefined behavior ?

编译器是intel12.我无法发布代码，因为它很大，而且我甚至不确定问题的根源是否在我的代码中.它可能在同事的图书馆中.我尝试使用gdb进行一些调试，但距离还很远.这是错误.

The compiler is intel 12. I can't post code because it's huge, and I am not even sure the source of problem is in my code. It may be in a colleague's library. I tried to do some debugging with gdb, but I don't get very far. This is the error.

malloc: *对象0x102302f20的错误:未分配正在释放的指针* 在malloc_error_break中设置一个断点以进行调试

malloc: * error for object 0x102302f20: pointer being freed was not allocated * set a breakpoint in malloc_error_break to debug

紧接其前的一行是打印*，关联的(指针)，打印为true.

The line immediately before that is a print *, associated(pointer), which prints true.

这是回溯

#0  0x00007fff9327b6c0 in malloc_error_break ()
#1  0x00007fff9327b805 in free ()
#2  0x0000000100d27470 in for_dealloc_allocatable ()
#3  0x0000000100506699 in sharedarraysmodule_mp_deleterealsharedarray2_ () at SharedArrays.f90:609
#4  0x00000001003bbc4e in gammaaggregatormodule_mp_deleteprivate_ () at GammaAggregator.f90:86
#5  0x0000000102300bc0 in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)

推荐答案

长注释，可能会(抱歉，无法抗拒)指向答案...

Long comment, might point (sorry, couldn't resist) towards an answer ...

为书呆子，似乎您的编译器的最佳猜测是未分配释放的指针".但是在Fortran中，指针仅具有 undefined ， associated 和 disassociated 状态，因此错误消息可能是由对编译器链接的系统函数的调用引起的到您的可执行文件中.

To be pedantic, it looks as if your compiler's best guess is 'pointer being freed was not allocated'. But in Fortran pointers only have statuses undefined, associated and disassociated so the error message may arise out of calls to the system functions which the compiler links into your executable.

话虽如此，我会寻找:

• 目标超出范围，而指向它的指针仍在范围内.Fortran 2003标准规定(注释16.13)

• A target going out of scope while a pointer to it remains in scope. The Fortran 2003 standard states (note 16.13)

可以在子程序中通过使用关联来访问来自模块程序单元的指针.此类指针的生存期大于子程序中声明的目标，除非保存了这些目标.因此，如果这样的指针与本地目标相关联，则存在当子程序定义的过程完成执行时，目标的可能性将不再存在，而使指针悬空".该标准认为此类指针具有未定义的关联状态.它们既没有关联也没有关联.他们不应该在程序中再次使用，直到重新建立其状态为止.不需要处理器能够检测何时不再存在指针目标.

A pointer from a module program unit may be accessible in a subprogram via use association. Such pointers have a lifetime that is greater than targets that are declared in the subprogram, unless such targets are saved. Therefore, if such a pointer is associated with a local target, there is the possibility that when a procedure defined by the subprogram completes execution, the target will cease to exist, leaving the pointer "dangling". This standard considers such pointers to have an undefined association status. They are neither associated nor disassociated. They shall not be used again in the program until their status has been reestablished. There is no requirement on a processor to be able to detect when a pointer target ceases to exist.

同一文档还指出，传递给 associated 内在的指针的关联状态不得未定义，因此程序可以撒谎并告诉您 associated(undefined_pointer)==.true..

The same document also states that the association status of the pointer passed to the associated intrinsic shall not be undefined so it's probably allowable for the program to lie and tell you that associated(undefined_pointer)==.true..

• 通过超出范围或由于 deallocate()调用而被释放的可分配目标.
• 指针在声明时被取消，例如， real，指针:: rptr =>null()(通常认为这是一件好事，您可能希望确保自己的代码符合要求.)
• 将指针关联之前先将其无效，但是根据标准，我不认为使空指针无效是一种错误.
• 指向指针的指针.

• An allocatable target being deallocated, either by going out of scope or as a result of a deallocate() call.
• Pointers being nullified on declaration, eg real, pointer :: rptr => null() (this is generally held to be a good thing, you might look to ensure that your code conforms).
• Pointers being nullified before they have been associated, though I don't think that nullifying a null pointer is an error according to the standard.
• Pointers to pointers.

您报告的错误消息往往表明您遇到了模块变量超出范围的情况，但是，正如您已经观察到的那样，很难确定.

The error messages you report tend to suggest that you have a case of module variables going out of scope, but, as you've already observed, it's kind of difficult to be certain.

如果这没有帮助，请与英特尔技术支持联系，我发现他们非常有帮助，他们非常擅长于发现自己代码中的问题.

If this doesn't help, contact Intel tech support, I find them very helpful, they are pretty good at spotting problems in one's codes.

这篇关于如何追踪潜在的不确定行为情况?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！