実践 9 つのメモリリークどう見つける？/ How to detect 9 types of memory leaks?iOS Test Online 2022/10/28 https://testonline.connpass.com/event/261910/
Xcodeのブレークポイントで音を鳴らす - いけだや技術ノート
Xcodeのブレークポイントでは音を鳴らすことができて、これは結構便利です。例えばシミュレーターの動作を目で確認する一方で、ブレークポイントを通過したかどうかは耳で確認することができます。シミュレーターの画面を見ながらコンソールのログを追うのは大変ですからね。 また "Automatically continue after evaluating actions" という実行を停止させないオプションと組み合わせるとさらによいですね。ちなみに僕は "Frog" の音が好きです。 Sound ActionとAutomatically continue after evaluating actions これは便利なので仕事中にもたまに使うことがありますが、その時には当然Macのミュートを解除する必要があります。そうすると今度はデバッグの最中にメールやSlackの通知音がオフィスに鳴り響いたりして
[Xcode 8][iOS 10] Xcode 8 の新機能！メモリ内の様子をビジュアル表示してくれる Debug Memory Graph | DevelopersIO
TestObject 型のインスタンス t1,t2,t3を作成します。t1がt2を参照、t2がt3を参照、t3がt1を参照といった形で、循環参照を実現しています。 実行 実行すると、Debug Memory Graph を表示するためのボタンがデバッグエリア上に現れます。 クリックすると、各クラスと、そのインスタンス一覧が表示されます。 例えば、このような形で Xcode の左ペインに表示されます。 メモリ上で各インスタンスがどのような関係で結びついているのかを確認するには、インスタンスをクリックすればOKです。 Xcode 8 ではこのように表示されます！ また、この表示画面で、各インスタンスをコマンドキーを押しながらクリックすると、コードの該当箇所（今回の場合TestObjectクラス）に飛ぶことが出来ます。 まとめ 概念図としてよく見るこうした図が、実際のメモリ内の状況を反映した形で
![[Xcode 8][iOS 10] Xcode 8 の新機能！メモリ内の様子をビジュアル表示してくれる Debug Memory Graph | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/368868dfcf6c8e0ce831c870623d748f4ae38563/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F09%2Fios10_400x400.png)
Xcode で快適なデバッグライフを追い求める
iOSDC https://iosdc.jp/2016/c/node/116 僕は怠惰な人間です。プログラミングの大半はデバッグに時間を費やすと思っているので、なるべく早く原因に辿りついたり効率のよいデバッグライフを送りたいと常々思っています。 プリントデバッグもいいのですが Xcode には便…
初級者から中級者にレベルアップするためのXcodeデバッグ術 - Think Big Act Local
効率よくiOSアプリ開発を行うために、効率よくデバッグを行いたいですよね。 このエントリでは「print文を書く以外デバッグの方法を知らなかったあの頃の自分」を初級者と定義して、自分がやってるデバッグ方法について書いてみます。 Xcodeデバッグ術 1. printを使わずに変数の中身を確認する age, name, coverImage という以下の3つの変数が宣言されています。 let age = 27 let name = "Ryosuke Hiramatsu" let coverImage = UIImage(named: "sample.jpg") これらの変数の中身をチェックしたい時、printで出力するのでも良いですが、それでは出力する値を変えたくなった時（print(age)をprint(age*2+1)に変更とか）に再度ビルドが必要になって時間がかかります。 printで
Cocos2d-xでゲームを作るときのタチの悪いメモリバグを追跡する - 無理な更新はお止めください。
個人開発者の方はこれで結構救われるんじゃないかな？ Cocos2d-xを使うゲームはC++で記述するので、メモリ関連のバグに悩まされるケースが多いと思います。Xcodeでデバッグしてその場所を突き止められるのならいいのですが、メモリのオーバーランなんかだとしばらく問題なく動いた後に突然訳のわからないところでエラーが出てアプリが落ちるということになってしまいます。こうなると原因を特定することは非常に困難です。コンソールゲームの開発であればグローバルなnewを拡張するなど独自のメモリ管理の仕組みを使ってこれを検出するのが通常のようですが、少々難易度が高いです。自分もどうするか悩んでいたところ、stackoverflowにこんな記事を見つけました。 stackoverflow.com 注目は二つ目の回答。なんとXcodeでそれを検出することができるのだそうです。Edit SchemeのDiagn
Xcode 5 で、発生した NSException の詳細が表示されない時の対処法
原因がよくわからないのですが、iOSアプリをデバッグ中にNSExceptionが発生してアプリがクラッシュしてしまった時、その詳細がXcodeのコンソール上に表示されなくなってしまいました。普通はデフォルトのexception handlerがうまい具合にやってくれるのですが、何らかの理由でそれがうまくいかない場合があるようです。自分でスレッド立ててるとかでしょうか・・・ 上図のように、例外が発生している箇所にブレークポイントをおいてどこで発生したのかを知ることはできるのですが、実際には発生箇所がわかっても発生原因がさっぱりわからないというケースもあります。例えばiOSのシステムが例外を発生させたときや、コードが公開されていないライブラリが例外を発生させたときなどです。 さて、このようなときは発生しているNSExceptionのdescriptionを直接読めれば便利そうです。というわけで
[Xcode][tool] ランタイムデバッガーSpark Inspectorが便利！ | Natsu note
デバッグ時にビューについての情報（重なりや位置、色など）を解析したくなることがよくあると思います。ビューの階層構造を知るための方法はいくつかありますが、先日見つけたSpark Inspectorがものすごく便利そうなのでご紹介します。 Spark Inspector – Runtime Debugger for iOS Apps Spark InspectorはBonjourとMethod Swizzlingを利用したランタイムデバッガーです。プロジェクトにフレームワークを追加し、起動のためのコードを記述するだけで簡単に利用できます（実際には、これらの作業もアシスタントが自動で行ってくれるので、ほぼボタン一つで利用可能になります）。 できることは大きく分けて二つ。 ビューの状態を2Dまたは3Dで表示する。ビューやレイヤーをリアルタイムで編集する。 通知センター(NSNotification
[紹介] Objective-C警告タイプのまとめ | Natsu note
アプリ開発時に最も苦労するのは何でしょう。多くの人がバグ取りとテストに時間を取られているのではないでしょうか。本来であれば、多くの時間はバグ取りではなく設計に費やしたいところです。 そこで役立つのがコンパイル時の警告。たかが警告、されど警告。あなどれません。ここには非常に多くのヒントが隠されています。私自身、常に警告はゼロにしていますが、コンパイルオプションを変えるとまだまだほかの警告が出てきます。 この警告レベルについて、非常に分かりやすくまとめられている記事がありました。 Compiler Warnings for Objective-C Developers – Ole Begemann 以下、概要のみまとめます。 3つの警告レベルオプション Xcodeのプロジェクトにてデフォルトで有効になっている警告はごく一部です。これは、プロジェクトのBuild Settingsにある”Appl
XCode4 と Instruments で実機動作中の NSZombie を探す方法
XCode4 と Instruments で実機動作中の NSZombie を探す方法¶ XCode4 で開発していると、予期しないインスタンスが解放されてしまって、そいつを 参照しようとして BAD_ACCESS が出てしまう事が有る。 しかし、いったい何を参照しようとしているのか、なかなか見つけ難い場合がある。 Cocoaではデベロッパ向けに「ゾンビオブジェクト」というアロケーションされていないメモリへのアクセスを見つける為に解放されたオブジェクトをNSZombieオブジェクトとしてリプレースされる機能があるので、BAD_ACCESSが発生した 際にそいつを見つけやすくすることができます。 NSZombie が有効な場合のXCode4 での debug output GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16
Xcode のコンソールにだって色をつけたい！
Xcode のコンソールには OS が出力したりと視認性がそこまでよくありません。 というわけで色付けできないかなと思ったらすぐにできたので紹介したいとおもいます。 robbiehanson/XcodeColors を clone してきて build するとインストールされます。 Xcode を再起動すると準備は万端です。 robbiehanson/CocoaLumberjack を使うとカラーリングやログレベルに応じた出力などが簡単にできて便利です。 みなさんよく使ってると思いますが、呼び出し元、行数を同時に出力するようなデバッグマクロを見やすくしてみようと思います。 これは自分で書いたメッセージをパっと見で分からないのがいけてないなと思ってました。 なのでカラーリングして見やすくしています。 結構みやすくなって個人的には気にいってます。 #define LOG(A, ...) \ N
中級者向け iOS デバッグ Tips - jarinosuke blog
導入 iOS 開発者のみなさん、こんにちは。 このブログでは主にチュートリアルだったりフレームワークの紹介みたいなことを書いてきました。 そこで、たまには中級者向けのエントリを書いて「Xcode バリバリ使って、ビシバシ Objective-C 書いてますよ」アピールします。 iOS 開発をはじめて一通り Framework は理解したけど Xcode 使いこなせてる感が足りない方、夢にまで EXC_BAD_ACCESS が出てくる方に参考になる記事となればと思います。 といっても Xcode はマッシブな IDE なので、4つのデバッグツールに分けて「あれ、それ知らなかった！便利じゃん！」な方法を紹介します。 ブレークポイント デバッグには切っても切れない関係ですね。アプリを実行中に指定した行で処理を中断し、そこからステップ実行で細かいデバッグを可能にしてくれます。 ショートカットキー
もう return UIApplicationMain で止まっても困らない! Xcodeでのデバッグ方法 – Zero4Racer PRO Developer's Blog
Xcode4.2 エラー画面 Xcode4になってから、いまいちデバッグがうまくいかない理由に、止まってしまう場所が、 return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); の行で止まってしまう場合が多いのがありますよね。この時に、どこで止まったのか分かるときはいいですが、いろいろな画面の中でどこで止まったか分からないときはデバッグ困りますよね。その対策法を見つけたので書いておきます。 試しに、エラーが起こるプロジェクトを作ってみました。 - (void)viewDidLoad { NSMutableArray *arrray = [NSMutableArray arrayWithCapacity:0]; [arrray objectAtIndex:10]; [super vie
Xcode4を使って複数台のiPhone/iPad実機の同時デバッグをやりたいねん。 | Eudyptes Chrysocome
March 2011 (1) December 2010 (2) September 2010 (2) June 2010 (1) March 2010 (1) January 2010 (3) December 2009 (1) November 2009 (2) October 2009 (4) September 2009 (1) August 2009 (4) July 2009 (4) June 2009 (4) May 2009 (1) April 2009 (3) March 2009 (1) February 2009 (11) January 2009 (4) December 2008 (2) November 2008 (5) August 2008 (3) July 2008 (6) June 2008 (1) May 2008 (2) April 2008 (1)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Xcodeの Memory graph を使った華麗なるデバッグ
第18回yidevで「まだNSLogで消耗しているの？」を発表してきました
Xcode ブレークポイント Tips
Xcode デバッグマスター
Cocoaの日々: Xcode4.1 デバッグ時のアセンブリ表示からの脱出