How to find reason for app crash on close?

问题

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?

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?

回答1:

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?

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:

*** set a breakpoint in malloc_error_break to debug.

(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)

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.

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.

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.

来源：https://stackoverflow.com/questions/38170727/how-to-find-reason-for-app-crash-on-close