ruby-debugを使ったRuby・Railsアプリケーションのデバッグ方法
gistfile1.md ruby-debugを使ったRuby・Railsアプリケーションのデバッグ方法 インストール # Ruby 1.8系の場合 gem install ruby-debug # Ruby 1.9系の場合 gem install debugger bundlerの場合は gem "ruby-debug" をGemfileに追記して bundle install します。 チュートリアル デバッガを起動する デバッグしたい場所で debugger メソッドをコールします。 class User def name debugger # ← これ puts "千早" end end rails consoleを --debugger オプション付きで起動します。 起動時にデバッガが有効になった旨のメッセージが出力されます。 script/console --debugger
Ruby 2.0 向けのデバッガー byebugについて - Qiita
Ruby 2.0系でのみ動作するdeivid-rodriguez/byebugというデバッガーが存在する事を知りました。 少し触ってみた所、2.0系とdebuggerではどうにも動作が不安定だったステップ実行がちゃんと実行できるし、動作も軽快で良い感じでした。 debuggerとの違いは以下のようになってます。 1.9系では動かない。2.0系のみ対応 2.0で追加されたデバッガ向けのC APIを利用しているため、MRIのソースに依存しないクリーンな実装。(debugger2みたいな感じ) debuggerで現在も残っているissueをいくつか解決している 特に正しいバックトレースを返してくれる点が良い 外部エディターサポートは組み込んでいない スレッドはまだサポートされていない。まだ新しいAPIでサポートされてないかららしい アクティブにメンテしてる pryコマンドを組込んでいるので、by
アセンブリ読んだら負けかなと思ってる - 誰かの役に立てばいいブログ
子供のころからできるだけ手抜きして成果を挙げることだけは長けている山本です。 今回は、C/C++ で作ったプログラムが運用中にクラッシュするときのデバッグ方法のお話しです。 開発中のデバッグは gdb などでソース追いながらデバッグできますが、運用中ですと strip していたり最適化していたりしてデバッグが難しくなります。 そもそも、いきなりクラッシュすると情報が残らずに困ってしまいます。そんなときどうするか。 Step1. スタックトレースを出力する こんな関数を用意しましょう。Linux 以外の人はそれなりに実装してください。 #include <execinfo.h> #include <unistd.h> void dump_stack() { void* bt[100]; int n = backtrace(bt, 100); backtrace_symbols_fd(bt,
GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
RubyやPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
[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
【iOS】 Xcode開発Tips入門編その3 -NSLogあれこれ3つほど- - @kitano_ow 's blog
第三弾です。 iOS向け Xcode開発Tips初級編 -とりあえず最初にやってること- iOS向け Xcode開発Tips初級編その2 -ちょっと便利なショートカットキー8つ- 今回は、NSLogのちょっとした使い方を。初回でも扱いましたけども、それとはちょっと違う視点で。 1.文字列へ変換して出力 CGRectやCGPointなどなど NSLog(@"%@",NSStringFromCGRect(self.view.frame)); 他にも色々ありますが、詳しくはこちらを UIKit Function Reference クラス名とかも同じ要領で NSLog(@"%@", NSStringFromClass([sender class])); 2.コールスタックを出す。 NSLog(@"%@" , [NSThread callStackSymbols]); ブレイクポイント張ったりすれ
NSLog デバッグ用の各種ログマクロまとめ - Qiita
追記: 良い子のみんなはこんなマクロを自分で定義する前にUIKit Function - String ConversionsとかCocoaLumberjackとか使うんだよ！！！！！ ログは出したいけどリリースビルド時には出したくないという時に使う各種ログマクロです。 個人的に使っているもののまとめです。(オープンソース見ているといろいろな種類見かけますね) プロジェクトを作るとテンプレで出来る「アプリ名-Prefix.pch」というヘッダに書くとどのソースでも使えるようになるので便利です。 # ifdef DEBUG #define LOG(...) NSLog(__VA_ARGS__) #define LOG_PRINTF(FORMAT, ...) printf("%s\n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UT
iOS向け Xcode開発Tips入門編 -とりあえず最初にやってること- - @kitano_ow 's blog
ちょっとした細かい事なんですけど、設定とかimportとか プロジェクトを跨がって使いそうなやつは最初にうちにやってること多いんですけど、 その辺のネタを少々・・・ 1.NSLogの拡張と、prefix.pch NSLogは、コンソールにその内容を出力してくれるわけですが、 NSLog(@"%s",__PRETTY_FUNCTION__); NSLog(@"%d",__LINE__); とすると、 __PRETTY_FUNCTION__：クラス及び関数名 __LINE__：行数 などを表示してくれます。 ただ、毎回これを記述するのは、 面倒なのでだいたいマクロにしたりしますが、 #define LOG(fmt,...) NSLog((@"%s %d "fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__); これをあるヘッダファイルなどに記述
RubyMotion のデバッグで NSZombieEnabled を使う - satococoa's blog
RubyMotion でアプリをつくるとき、デバッグがやはり大変です。 例えば GCD など非同期で実行されるブロック内で参照されるオブジェクトをインスタンス変数に入れていない場合、実際にそのブロックの処理が実行されるときには既にそのオブジェクトが解放されてしまっているというケースがあります。 これが RubyMotion を使う上での一番厄介なハマりどころといえると思います。 そのケースにハマった場合、何も有用なログを残さずにすとんと落ちてしまうことがありとても萎えます。 例えば以下の例はあまりに単純すぎますが、当然アプリがすとんと落ちます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # app_delegate.rb class AppDelegate def application(application
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://tech-gym.com/2013/08/ios/1292.html
Running Apple instruments for Automation from Terminal
LLDB ブレークポイント tips
Xcode ブレークポイント Tips
Coming Soon
NSLogでblocksのシグネチャ出力を可能にする
GitHub - ko1/debugger2: port of debugger that works on MRI 2.0.0
デバッグログをオーバレイするカスタムウィンドウ