Pythonで本当に役立つ機能「アサーション」の使い方を解説！『Pythonトリック』から
皆さんはPythonの強みを最大限に発揮できているでしょうか。翔泳社から発売した『Pythonトリック』は、その強みの数々をTIPS集としてまとめた1冊です。今回は本書から、コードのエラーを自動的に検出しプログラムの信頼性を高められる機能「アサーション」について抜粋して紹介します。 本記事は『Pythonトリック』の「CHAPTER 2 よりクリーンなPythonのためのパターン」から抜粋したものです。掲載にあたり一部を編集しています。 2.1 アサーションによる安全対策 本当に役立つ言語の機能が案外に注目されないことがあります。どういうわけか、これに該当するのがPythonの組み込みのassert文です。 ここでは、Pythonでのアサーションの使い方をざっと紹介します。アサーションを使ってPythonプログラムでエラーを自動的に検出する方法がわかるでしょう。このようにすると、プログラム
gdbで効率的にデバッグするためのTips
Tips for Productive Debugging with GDBの抄訳。 Tips 1: GDB Dashboardを使おう GDB Dashboardは単一の.gdbinitファイルで、ブレークポイントで止まるたびに下図のようなクールな画面を表示してくれる。 https://github.com/cyrus-and/gdb-dashboard gdbには標準でTUIモード（cursesベースのUI）が搭載されているが、そちらは画面の乱れが頻繁に起こる。GDB Dashboardはcursesを使っていないので乱れが起きない。 スクショではOutput/messages, Source, Assembly, Threadsなど多数のモジュールを全部入りで表示しているためゴチャゴチャしているが、設定で自分に必要なモジュールだけを表示するようにできる。 訳者もしばらく使っているが、
ソフトウェアが止まったり落ちたりした状態をgdbで解析する - 千里霧中
ソフトウェアがデッドロックや無限ループ等で応答しなくなったり、Segmentation Fault等で強制終了したりする場合での、gdbを使った解析手法について簡単なまとめ。 なお今回の内容はunixやlinux開発での基本知識となっていると思うけれど、例えば組み込みlinux開発などでは活用できるのを知らずに、printfデバッグで頑張っている所が結構あるようだ。開発が楽になるので基礎として知っておいて損はないと思う。 ソフトウェアが落ちる状態の解析 まず例外発生などでソフトウェアが異常終了する場合の解析について。 例えば以下のコードを実行すると、メモリアクセスエラーで異常終了する。 //main.c void hoge1(void) { int *hoge = (int *)0xDEADBEEF; hoge[0] = 100; } void hoge2(void) { hoge1();
[Xcode][tool] ランタイムデバッガーSpark Inspectorが便利！ | Natsu note
デバッグ時にビューについての情報（重なりや位置、色など）を解析したくなることがよくあると思います。ビューの階層構造を知るための方法はいくつかありますが、先日見つけたSpark Inspectorがものすごく便利そうなのでご紹介します。 Spark Inspector – Runtime Debugger for iOS Apps Spark InspectorはBonjourとMethod Swizzlingを利用したランタイムデバッガーです。プロジェクトにフレームワークを追加し、起動のためのコードを記述するだけで簡単に利用できます（実際には、これらの作業もアシスタントが自動で行ってくれるので、ほぼボタン一つで利用可能になります）。 できることは大きく分けて二つ。 ビューの状態を2Dまたは3Dで表示する。ビューやレイヤーをリアルタイムで編集する。 通知センター(NSNotification
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
中級者向け iOS デバッグ Tips - jarinosuke blog
導入 iOS 開発者のみなさん、こんにちは。 このブログでは主にチュートリアルだったりフレームワークの紹介みたいなことを書いてきました。 そこで、たまには中級者向けのエントリを書いて「Xcode バリバリ使って、ビシバシ Objective-C 書いてますよ」アピールします。 iOS 開発をはじめて一通り Framework は理解したけど Xcode 使いこなせてる感が足りない方、夢にまで EXC_BAD_ACCESS が出てくる方に参考になる記事となればと思います。 といっても Xcode はマッシブな IDE なので、4つのデバッグツールに分けて「あれ、それ知らなかった！便利じゃん！」な方法を紹介します。 ブレークポイント デバッグには切っても切れない関係ですね。アプリを実行中に指定した行で処理を中断し、そこからステップ実行で細かいデバッグを可能にしてくれます。 ショートカットキー
gcc+gdbによるプログラムのデバッグ 第2回 変数の監視、バックトレース、その他のコマンド
前回までに、デバッガを使用する上での最低限のことを覚えました。 ステップ実行 変数の表示、変更 ブレークポイント 今回は少しレベルを上げて、よりデバッガを使いこなすためのコマンドを紹介します。 ウォッチポイント ウォッチポイントはブレークポイントに近いものですが、ブレークポイントのように「ある地点に遭遇したら停止」ではなく、「監視している変数を操作したら停止」という流れになります。 ファイル内から該当する変数名を探せばいいと考えるかもしれませんが、C言語ではポインタによる変数の別名を付けることが可能であるため、そう単純にはいきません。 書き込みの監視 あまりよいサンプルが思いつかなかったため、簡単で無意味な例を示します。 counter.c #include <stdio.h> void set_counter(int *); int count = 1; int watchee = 0;
iOSアプリ開発で例外の発生した場所を特定する | DevelopersIO
iOSアプリを開発していて、例外が発生してアプリがクラッシュしてしまうことがしばしばあります。 Xcodeでは、クラッシュ時に得られる情報が少ないので、原因究明に時間がかかってしまいます。 そんなときは、「NSSetUncaughtExceptionHandler」を使用すると便利です。 まず、試しに、よくある例外をわざと発生させてみます。 - (void)viewDidLoad { [super viewDidLoad]; // ここで、わざと例外を発生させてみます。 [[NSArray array] objectAtIndex:0]; } 実行すると以下のようになります。 「UIApplicationMain」で止まってしまって、状況がよくわかりません。 「NSRangeException」が発生したことくらいはわかりますが、もう少し情報が欲しいところです。 そこで、「NSSetUnc
Flexible iOS Logging - Kazzz's diary
Flexible iOS Logging « The Brenwill Workshop Flexible iOS LoggingはBill Hollings氏によるCocoa Touch SDKの開発で使用することができるロギングライブラリィ。 元々Cocoa TouchにはNSLogというロギングのためのライブラリィがあるが、これはprintf同様の非常に簡易なものであり、 ロギングレベル(info/error/debug ..etc.)が選べない 条件を設定することが出来ずに必ず実行されてしまう という弱点があるが、"Flexible iOS Logging"を使うことで簡単にそれを解決することができる。 使い方は非常にシンプルであり、 1.Logging.hをインクルードする 2.ロギングのためのマクロを呼び出す これだけである。 既に内部ではレベル分けがされており、 LogTra
gdb で void* 型の変数をデバッグする
C言語で実装されたライブラリやアプリケーションでは、汎用的な型として随所で void* が使用されますが、これをgdbからデバッグすると、そのままでは型情報が無いためタダのポインタとして扱われてしまいます。これではデバッグ時の都合がよろしくないです。 (gdb) print 0xfee65c0 $1 = 267281856 (gdb) print (void *)0xfee65c0 $2 = (void *) 0xfee65c0 こんなとき、この void* が指し示している先の型がわかりきっている場合は、その型でキャストしてやって: (gdb) print (struct imap_session_state_data *)0xfee65c0 $4 = (struct imap_session_state_data *) 0xfee65c0 (gdb) print $4 $5 = (st
NSObject:description メソッドを簡単に実装できる DescriptionBuilder を公開しました。 - 24/7 twenty-four seven
kishikawakatsumi/DescriptionBuilder · GitHub NSObject クラスの description メソッドをオーバーライドしておくと、NSLog で出力できたりしてデバッグ時に便利です。 ただ、出力する項目が増えてくると、結構な手間になるので、リフレクションを使って自動ですべてのインスタンス変数を出力できるようにしてみました。 このクラスを使うと、description メソッドは次のように書けます。 - (NSString *)description { return [DescriptionBuilder reflectDescription:self]; } このようなオブジェクトの場合、デフォルトでは下記のようにフォーマットされて出力されます。 @interface Settings : NSObject { NSUInteger ver
atos を使ってアプリのクラッシュログを symbolicate する方法
iOSアプリがクラッシュするとクラッシュログがデバイスに残され、 Xcode のオーガナイザーからログを取得してバグの原因を解析できるのは皆さんご存知の通りだと思います。このとき、基本的には Xcode がクラッシュログがの中のシンボルを自動的に読める状態にしてくれる (symbolicate) のですが、どうも Xcode 4 になってからこの symbolicate がいまいちよく動いてくれないので、手動で symbolicate をする方法を調べてみました。 参考にしたページは以下の通り。 http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports ■atosの使い方 symbolicate をするには Xcode に付属している atos というコマンドラインツールと、ビルドの際
Big Sky :: C++でcoutやcerrの挙動を変える。
先日twitterで「C++でデバッグする時、よくやるよね」って言ったら結構知らない人がいたのでここでも紹介してみる。 既存のコードでcout/cerrを使ったデバッグ文がわんさかあって、これログファイルとして出力したいな...って場合ありますよね。 そんな場合 #include <iostream> #include <fstream> using namespace std; int main() { // こんなの ofstream ofs("debug.log"); cout.rdbuf(ofs.rdbuf()); // いれとく cout << "debug string" << endl; } こうしておくと、その後のcoutへの出力が全てdebug.logというファイルへ出力される。 なおrdbufを元に戻すには #include <iostream> #include <f
【iPhone】メモリ不足時のシミュレートとデバッグ | iphoneアプリで稼げるのか
iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ
2010-09-10
アプリ開発をしているときに、EXC_BAD_ACCESSが発生してしまうと原因不明でアプリが落ちてしまう。デバッガでどこで落ちるのか探して、原因となる行を特定して修正ということになるけども、もっと楽な方法が欲しい。 そこで出てくるのがNSZombieEnabledを有効にするというはなし。 設定方法は簡単 プロジェクトメニュー => アクティブな実行ファイル"○○"を編集 を開き「引数」タブをクリック。上下二つの設定項目のうち「環境に設定される変数」に設定 これで、EXC_BAD_ACCESS発生してもデバッガコンソールにより詳細な情報が出てくれる。便利めちゃ便利。 iPadアプリを作る場合には、かならず回転に対応した状態で作らなければならぬらしい。 結論を先に言うと、Window-basedを使わずView-basedを使えと。 回転対応するにはUIViewController追加する。
iPhoneアプリ開発におけるデバッグのTIPS
2011-2-28 NSLogの出力を分りやすくするを修正しました。 新型MacBookAirをケーキ入刀用に買おうとしてるみなさんこんにちは。ダニーです。 iPhoneアプリ開発をしてるとメモリ周りで落ちることがあってデバッグするのが大変ですね， 今回はデバッグについて紹介したいと思います。 CGRectの中身を表示する CGRect rect = CGRectMake(13, 30, 100, 200); NSLog(@"%f %f %f %f", rect.origin.x, rect.origin.y, rect.size.width, rect.size.height); NSStringFromCGRectを使うと簡潔になります。 CGRect rect = CGRectMake(13, 30, 100, 200); NSLog(@"%@", NSStringFromCGRec
gdb の使い方・デバッグ方法まとめ
たとえば、変数 var の値を2進数で表示したい場合は、次のように指定します。 (gdb) p/t var 一覧表示 whatis 変数の型を調べる。 info b 今設定しているブレークポイントの一覧を表示 セグメントフォルトをした後に利用すれば、どの関数で発生したか確認できます。 info stack 関数の呼び出しスタックの一覧を表示 info Thread 存在しているスレッドの一覧を表示 異なるアドレスにおける処理継続 以下のコマンドを使用することで、ユーザが選択したアドレスにおいて実行を継続させることができます jump linespec linespecで指定される行において、実行を再開 jump *address addressで指定されるアドレスにある命令から、実行を再開 アドレスが分かっている場合のメモリリーク出力 xはhexの意味です。 (gdb) p (char*)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
英語版WindowsでTera Termがクラッシュする問題を調査した話｜Yutaka Hirata
メソッドの実行時間計測ライブラリと TheWrapper
Loading
