如何找到应用程序崩溃的原因关闭？ [英] How to find reason for app crash on close?

问题描述

当我点击关闭窗口返回时，我的Qt5应用崩溃：

My Qt5 app crashes when I hit the close window returning:

MyApp(28741,0x7fff7aa73000) malloc: *** error for object 0x7fc40bc8e300: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
The program has unexpectedly finished.

经典的方法来恢复它，我想是，禁用应用程序模块（我应该说它的部分

Classic approach to recover it, I guess, is to disable application modules (should I say parts of it, when things are not so well organized) systematically until the problem appears.

有更多的智能方法来解决这个问题吗？

Is there some (more) intelligent way to solve this issue?

从返回的问题很明显，有指针被删除（至少）两次。但是这是隐藏吗？

From what has been returned the problem is obvious, there is pointer somewhere being deleted (at least) two times. But were is this thing hiding?

我可以使用 28741,0x7fff7aa73000 做什么？和 0x7fc40bc8e300 ？我可以使用这些在Mac上的Qt Creator 4中找到什么？

What can I do with 28741,0x7fff7aa73000? And with 0x7fc40bc8e300? Can I use those to find something in Qt Creator 4 on Mac?

因为应用程序崩溃关闭它意味着问题是在析构函数？

Because the app crash on close it means the problem is in a destructor?

推荐答案

从返回的问题很明显，有指针被删除（至少）两次。但是这是隐藏吗？

From what has been returned the problem is obvious, there is pointer somewhere being deleted (at least) two times. But were is this thing hiding?

不完全是;你说的话通常是双自由的;这似乎更像是某人从 malloc 传递到 free 的东西。

Not exactly; what you say is normally signaled as a "double free"; this seems more like somebody is passing to free something that never came from malloc.

要准确定位，请按照消息说：

To pinpoint it, do as the message says:

***在<$ c $中设置断点c> malloc_error_break 以调试。

（或者真的，当程序中止时，它会在堆栈顶部插入调试器）

(or really, even just run it under a debugger; normally on Linux it does break into the debugger at the top of the stack when the program is aborted)

一旦断点被​​触发，调用堆栈，看看什么指针被释放，并尝试找到它是什么时候释放它实际上不是来自 malloc 。

Once the breakpoint is hit, walk up the call stack and see what pointer is being freed, and try to find out why it is being freed when it doesn't actually come from malloc.

地址是big（0x7fc40bc8e300）的事实表明它可能来自堆栈（如果OS X是Linux，堆在内存中down，堆栈是虚拟地址空间的对面），所以很可能只是传递给 free 或 delete 地址来自堆栈。这通常发生在你错误地传递一个堆栈分配的对象到一个方法，想要取得它的所有权并释放它 free 或 delete <

The fact that the address is "big" (0x7fc40bc8e300) tells that it probably comes from the stack (if OS X is anything like Linux, the heap is "down" in memory, the stack is at the opposite side of the virtual address space), so probably it's just as simple as somebody passing to free or delete an address that comes from the stack. This often happens when you erroneously pass a stack-allocated object to some method that wants to take ownership of it and free it with free or delete when it isn't needed anymore.

此外，运行valgrind不会伤害，但我怀疑，在这种情况下，它可以是任何帮助 - 你似乎没有处理一个无效的指针（它会在第一次读/写时检测到），但是你有一个有效的非堆分配的指针，它被不正确地释放 free 。它可能会在 free 本身的同时检测它。

Also, running valgrind never hurts, but I doubt that in this case it can be of any help - you don't seem to be dealing with an invalid pointer (which it would detect at the first read/write), but you have a valid non-heap-allocated pointer that is being incorrectly deallocated with free. It will probably detect it at the same time as free itself.

这篇关于如何找到应用程序崩溃的原因关闭？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！