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

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:

***在 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.