閉じるとアプリがクラッシュする理由を見つける方法はありますか？

Question

マイQt5アプリがクラッシュし、私はこのウィンドウを閉じるには戻って打つ：私はそれの部品言うべき事は非常によく組織化されていないときにそれを回復する

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. 

クラシックアプローチは、私が推測する、（アプリケーションモジュールを無効にすることです）問題が現れるまで体系的に分析します。

この問題を解決するにはもっと知的な方法がありますか？

返されたことから、問題は明らかです。ポインタは少なくとも2回は削除されています。しかし、これは隠れていたのですか？

28741,0x7fff7aa73000で何ができますか？ 0x7fc40bc8e300？ MacでQt Creator 4で何かを見つけるのにそれらを使うことはできますか？

アプリが閉じるとクラッシュするため、問題はデストラクタにあることを意味しますか？

Answer 1

何が返されているのかは明らかですが、どこかに（少なくとも）2回削除されているポインタがあります。しかし、これは隠れていたのですか？

正確ではありません。あなたが言うことは、通常、「ダブルフリー」として通知されます。誰かがfreeに渡ってきたように、これは決してmallocから来たものです。

、それを特定のメッセージが言うように行うには：

を***は、デバッグにmalloc_error_breakにブレークポイントを設定します。

（または実際に、だけでも、デバッガの下でそれを実行し、プログラムが中断されたとき、通常はLinuxのそれは、スタックの上部にデバッガに侵入ん）

ブレークポイントにヒットしたら、呼び出しスタックを移動して解放されているポインタを確認し、実際にはmallocから来ていないときに解放されている理由を調べようとします。

アドレスが "big"（0x7fc40bc8e300）であるということは、おそらくスタックから来ていることを示しています（OS XがLinuxのようなもので、ヒープがメモリ内に "ダウン"していればスタックは反対側です仮想アドレス空間）。おそらく、誰かがfreeまたはdeleteにスタックから来るアドレスを渡すことと同じくらい簡単です。これは、スタック割り当てオブジェクトを誤って所有権を取得し、それが不要になったときにfreeまたはdeleteで解放しようとするメソッドに誤って渡したときによく発生します。

また、valgrindを実行することは決してありませんが、この場合、それは無効なポインタ（最初の読み取り/書き込み時に検出される）を扱うようには思われません。 freeで間違って割り当てが解除されている有効なヒープ割り当てされていないポインターがあります。おそらくfreeそのものと同時に検出されます。