中止核心转储 C++
我有一个大型 C++ 函数，它使用 OpenCV 库并使用 cygwin g++ 编译器在 Windows 上运行。最后它给出 Aborted(core dumped) 但函数在此之前完全运行。我还尝试将 print 语句放在函数的末尾。这也会被打印出来。所以我认为代码中不存在会产生故障的逻辑错误。
请解释一下。
我也在使用断言语句。但是中止的错误不是由于断言语句造成的。它并没有说断言失败。它只有在没有任何消息的情况下才出现。
此外，该文件是一个大型项目的一部分，因此我也无法发布代码。
gdb结果：
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通过 AppVerifier 运行它并 < a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx" rel="nofollow noreferrer">cdb。
例如
Run it through AppVerifier and cdb.
E.g.
它看起来像是内存错误（写入已释放的内存、双重释放、堆栈溢出......）。当代码可以在 Linux 下编译并运行时，您可以使用 valgrind 查看是否存在内存问题。此外，您还可以尝试禁用应用程序的部分内容，直到问题消失，以获取错误发生位置的线索。但这种方法也可能会产生误报，因为与内存相关的错误可能会导致模块失败，而这并不是错误的原因。您也可以在 gdb 中运行该程序。但这里调试器指向的位置也可能不是发生错误的位置。
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
你没有给我们太多继续下去的机会。但是，这看起来您在释放资源时遇到了一些问题。也许是堆损坏。您是否尝试过在 gdb 下运行它然后查看它崩溃的位置？另外，检查所有新的/删除的呼叫是否匹配。
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
将核心转储与二进制文件一起加载到 gdb 中，以了解问题列表的位置。命令行是：
有关 gdb 的更多详细信息，请参见 GDB：GNU 项目调试器。
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
For more details on gdb see GDB: The GNU Project Debugger.