2

XCodeの最新バージョン（これは4.2かそこらから起こっていると思います）で多くのインスタンスに遭遇しています。例外がスローされたときのスタックトレースには、ひどく詳細が欠けています。

ここでのスクリーショットは、そのようなケースの1つを示しています。実際、このシナリオには少なくともいくつかのコンテキストがあり（ JKArrayクラスで発生したことを示しています）、多くの場合、「内部」スタックアイテム（スレッド内の2〜3エントリのみ、いずれもに存在しない）しか取得しません。ユーザーコードまたは私が見ることができるもの）。この例でも、JKArrayがどこに割り当てられたり解放されたりしたのかわからないので、どのインスタンスやどこに問題があるのか​​わかりません。

ここに画像の説明を入力してください

考え：

  • 一般的な「例外時」ブレークポイントを追加してみました
  • 出力にはいくつかのマイナーな情報があります。この場合： "malloc：*オブジェクト0x10e18120のエラー：解放されるポインターが割り当てられませんでした*デバッグするためにmalloc_error_breakにブレークポイントを設定してください"。ただし、これを行っても、ブレークポイントは例外と同じスタックでヒットするため、これ以上は取得できません...
  • 他のデバッガに切り替えてみました
  • 独自のカスタム例外ハンドラーを使用してみました
  • プロファイラーを使用してリークを探してみました。私が見つけることができる漏れはありません。

私が何をしても、アプリを悩ませている問題を切り分けることができないようです。さらに、問題は毎回まったく同じではないようです。これはおそらく、アプリの同時実行性が高いためです...そのため、問題を修正するための適切な方法がありません。

編集：この特定の例外の場合、私は原因を見つけることになりました。[リリース]して[自動リリース]されたオブジェクトを作成しようとしました。しかし、これはすべて私のコード内で起こっていました。XCodeが、アプリ全体を探すように強制するのではなく、問題を見つけるのに役立つ適切なスタックトレースを提供しない理由を理解できません...

4

1 に答える 1

1

症状の原因となる問題がはるかに早く発生したため、実際の問題を特定できない場合があります。

あなたの問題は素晴らしい例を提供します：あなたがあなたのオブジェクトを解放するとき、ココアはあなたが何か間違ったことをしたことを知りません：あなたはあなたが所有するオブジェクトを解放しています、これはまさにあなたがすべきことです、それで危険信号はありません。ブレークダウンにつながるコードは、メソッドが終了した後で十分に実行され、制御を実行ループに戻します。この時点で、実行ループが自動解放プールを使い果たし、2番目の割り当て解除が発生します。ただし、この時点でわかっているのは、実行ループがコードではなく、無効な割り当て解除を行ったことだけです。エラーが発生するまでに、犯人は安全にスタックから外れている（そしてフックから外れている）ので、Xcodeがあなたに報告できるものは他にありません。

このような問題の解決策は、メモリ使用量をプロファイリングすることです。プロファイラーは、そのような問題をキャッチし、それらが発生する場所を特定する必要があります。

言うまでもなく、自動参照カウントに切り替えることで、メモリ管理部門の多くの問題を回避できます。

于 2012-07-29T03:43:46.287 に答える