アプリケーションをデバイスにデプロイすると、プログラムは数サイクル後に次のエラーで終了します。
Program received signal: "EXC_BAD_ACCESS".プログラムはiPhoneシミュレーターで問題なく実行されます。また、命令を1つずつ実行する限り、デバッグして実行されます。もう一度走らせたらすぐにEXC_BAD_ACCESS信号を打ちます。
この特定のケースでは、それは偶然にも加速度計コードのエラーでした。シミュレーター内では実行されないため、エラーはスローされませんでした。ただし、デバイスに展開されると実行されます。
この質問に対する回答のほとんどは一般的なEXC_BAD_ACCESSエラーを扱っているため、恐ろしい不正アクセスエラーのキャッチオールとしてこれを開いたままにしておきます。
EXC_BAD_ACCESS通常、不正なメモリアクセスの結果としてスローされます。詳細については、以下の回答をご覧ください。
EXC_BAD_ACCESS以前に信号に遭遇したことがありますか？どのように対処しましたか？
回答:
あなたの説明から、私は最も可能性の高い説明はあなたがあなたのメモリ管理にいくつかのエラーを持っていることだと思います。あなたは数週間iPhone開発に取り組んできたと言いましたが、一般的にObjective Cの経験があるかどうかは違います。別の経歴を持っている場合、メモリ管理ルールを実際に内部化するまでに少し時間がかかることがあります。
割り当て関数（通常は静的allocメソッドですが、他にもいくつかあります）、またはコピーメソッドから取得したものはすべてメモリを所有し、完了時に解放する必要があります。
しかし、ファクトリーメソッド（例：）を含む他のほぼすべてから何かを取得した場合[NSString stringWithFormat]、自動解放参照があります。つまり、将来的に他のコードによって解放される可能性があるため、必要な場合に不可欠です。あなたがそれを保持する当面の機能を超えてそれを維持するため。そうしないと、エミュレーターのテスト中に、メモリの使用中にメモリが割り当てられたままになるか、解放されますが、偶然にも有効ですが、デバイスで実行すると、解放されて不良アクセスエラーとして表示される可能性が高くなります。
これらを追跡する最良の方法、そしてとにかく（明らかな問題がない場合でも）良いアイデアは、特にリークオプションを使用して、Instrumentsツールでアプリを実行することです。
EXC_BAD_ACCESSの主な原因は、解放されたオブジェクトにアクセスしようとしたことです。
これをトラブルシューティングする方法を見つけるには、このドキュメントを読んでください： DebuggingAutoReleasePool
「自動解放オブジェクトを解放する」とは思わなくても、これはあなたに適用されます。
この方法は非常にうまく機能します。ずっと使って大活躍!!
要約すると、CocoaのNSZombieデバッグクラスとコマンドラインの「malloc_history」ツールを使用して、コード内でアクセスされたリリース済みオブジェクトを正確に見つける方法を説明します。
サイドノート：
Instrumentsを実行してリークをチェックしても、EXC_BAD_ACCESSのトラブルシューティングには役立ちません。私はメモリリークがEXC_BAD_ACCESSとは何の関係もないと確信しています。リークの定義は、アクセスできなくなったオブジェクトであるため、呼び出すことはできません。
更新： リークのデバッグにInstrumentsを使用しています。Xcode 4.2から、[製品]-> [プロファイル]を選択し、Instrumentsが起動したら、[ゾンビ]を選択します。
EXC_BAD_ACCESSシグナルは、無効なポインターをシステムコールに渡した結果です。今日、OS Xのテストプログラムで1つ取得しました。初期化されていない変数をに渡していましたpthread_join()。これは、以前のタイプミスが原因でした。
私はiPhoneの開発に精通していませんが、システムコールに渡すすべてのバッファーポインターを再確認する必要があります。コンパイラの警告レベルを完全に上げます（gccを使用する場合は、-Wallおよび-Wextraオプションを使用します）。シミュレータ/デバッガで可能な限り多くの診断を有効にします。
私の経験では、これは通常、不正なメモリアクセスが原因です。すべてのポインター、特にオブジェクトポインターをチェックして、それらが初期化されていることを確認します。MainWindow.xibファイルを使用している場合は、必要なすべての接続が正しく設定されていることを確認してください。
紙面での確認で問題が解決せず、シングルステップで問題が発生しない場合は、NSLog（）ステートメントでエラーを見つけてください。コードを振りかけ、原因となっている行を特定するまで移動してください。エラー。次に、その行にブレークポイントを設定し、プログラムを実行します。ブレークポイントに到達したら、すべての変数とその中のオブジェクトを調べて、期待どおりに見えないものがないか確認します。特に、オブジェクトクラスが予期しないものである変数に注意します。変数にUIWindowが含まれているはずなのに、代わりにNSNotificationが含まれている場合、デバッガーが動作していないときに、同じ基本的なコードエラーが別の方法で現れている可能性があります。
数時間かけてEXC_BAD_ACCESSを追跡したところ、NSZombiesと他の環境変数が何も教えてくれないようでした。
私にとっては、フォーマット指定子を含むが、引数が渡されない愚かなNSLogステートメントでした。
NSLog(@"Some silly log message %@-%@");によって修正
NSLog(@"Some silly log message %@-%@", someObj1, someObj2);完全な答えではありませんが、これを受け取った特定の状況の1つは、自動解放を使用しようとしたために「死んだ」オブジェクトにアクセスしようとしたときです。
netObjectDefinedInMyHeader = [[[MyNetObject alloc] init] autorelease];たとえば、私は実際にこれを「通知」するオブジェクトとして渡しました（リスナー、オブザーバー、好きなイディオムとして登録しました）が、通知が送信されるとすでに終了しており、EXC_BAD_ACCESSを取得します。変更し[[MyNetObject alloc] init]て後で適切にリリースすると、エラーが解決しました。
これが発生するもう1つの理由は、たとえば、オブジェクトを渡してそれを保存しようとした場合です。
myObjectDefinedInHeader = aParameterObjectPassedIn;後でmyObjectDefinedInHeaderにアクセスしようとすると、問題が発生する可能性があります。使用：
myObjectDefinedInHeader = [aParameterObjectPassedIn retain];あなたが必要とするものかもしれません。もちろん、これらは私が遭遇したことのほんの数例であり、他の理由もありますが、これらはとらえどころのないものになる可能性があるので、それらについて言及します。幸運を！
これが起こり得る別の状況を追加するだけです：
私はコードを持っていました：
NSMutableString *string;
[string appendWithFormat:@"foo"];明らかに、文字列にメモリを割り当てるのを忘れていました。
NSMutableString *string = [[NSMutableString alloc] init];
[string appendWithFormat:@"foo"];問題を修正します。
objc_exception_throwにブレークポイントを設定すると便利です。そうすれば、EXC_BAD_ACCESSを取得したときにデバッガーが壊れます。
手順はここにありますDebuggingTechniques
上記のリンクを確認して、記載されているとおりに実行してください。
アプリケーションを実行し、失敗した後（「EXC_BAD_ACCESS」ではなく「Interrupted」と表示する必要があります...コンソールを確認します（[実行]> [コンソール]）...アクセスしようとしているオブジェクトを示すメッセージが表示されます。
-ベン
このエラーを解決するために、過去4時間、コードのデバッグとリファクタリングを行ってきました。上記の投稿で問題が発生しました。
前のプロパティ：startPoint = [[DataPoint alloc] init]; startPoint = [DataPointList objectAtIndex：0];
。。。x = startPoint.x-10; // EXC_BAD_ACCESS
後のプロパティ：startPoint = [[DataPoint alloc] init]; startPoint = [[DataPointList objectAtIndex：0]保存];
さようならEXC_BAD_ACCESS
完了したら「ストリング」を解放してください。
これは優れたスレッドです。これが私の経験です。私はプロパティ宣言の保持/割り当てキーワードをめちゃくちゃにしました。私は言った：
@property (nonatomic, assign) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, assign) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, assign) IBOutlet UISwitch *asiaSwitch;私が言っておくべきだった場所
@property (nonatomic, retain) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, retain) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, retain) IBOutlet UISwitch *asiaSwitch;大きな配列を含むCメソッドを実行しようとしたときにのみ、iPhoneでEXC_BAD_ACCESSが発生しました。シミュレータはコードを実行するのに十分なメモリを私に与えることができましたが、デバイスには与えられませんでした（配列は100万文字だったので、少し過剰でした！）。
EXC_BAD_ACCESSはメソッドのエントリポイントの直後に発生し、配列宣言の近くにないため、しばらく混乱していました。
おそらく、誰かが私の髪を引っ張る数時間から恩恵を受けるかもしれません。
から割り当てられていないポインタを取り出すのを忘れましたdealloc。UINavigationControllerのrootViewでexc_bad_accessを取得していましたが、ときどきしかありませんでした。viewDidAppear {}の途中でクラッシュしたため、問題はrootViewにあると思いました。それは私が悪いdealloc {}リリースでビューをポップした後にのみ起こりました、そしてそれだけでした！
"EXC_BAD_ACCESS" [プロセス330への切り替え]プログラムに使用できるメモリがありません：mallocを呼び出すのは安全ではありません
私がアロケートしようとしているところの問題だと思った...アロケートを解放しようとしているところではない、D'oh！
メソッドパラメータを検証するNSAssert（）呼び出しは、追跡を行い、nilを渡さないようにするのにも非常に便利です。
このエラーを解決するために、過去4時間、コードのデバッグとリファクタリングを行ってきました。上記の投稿で問題が発生しました。
前のプロパティ：
startPoint = [[DataPoint alloc] init] ;
startPoint= [DataPointList objectAtIndex: 0];
x = startPoint.x - 10; // EXC_BAD_ACCESS後のプロパティ：
startPoint = [[DataPoint alloc] init] ;
startPoint = [[DataPointList objectAtIndex: 0] retain];さようなら EXC_BAD_ACCESS
回答ありがとうございます。私は一日中この問題に取り組んできました。あなたは素晴らしいです！
追加するだけ
Lynda.comには、素晴らしいDVDと呼ばれています。
第6章、レッスン3では、EXEC_BAD_ACCESSとゾンビの操作について説明します。
エラーコードだけでなく、リリースされたオブジェクトの詳細情報を取得するためにZombiesをどのように使用できるかを理解できたのは素晴らしいことでした。
私はこれが少し前に尋ねられたことに気づきましたが、このスレッドを読んだ後、私はXCode 4.2のソリューションを見つけました：製品->スキームの編集->診断タブ->ゾンビオブジェクトを有効化
割り当て解除されたオブジェクトに送信されているメッセージを見つけるのに役立ちました。
無限再帰がある場合、このエラーも発生する可能性があると思います。これは私の場合でした。
XCode 4以降では、Instrumentsを使用して非常にシンプルになっています。ゾンビをインストゥルメントで実行するだけです。このチュートリアルはそれをうまく説明します：exc_bad_accessエラーxcode計測器のデバッグ