GDB でレジスタを見る - higepon blog
GDB でレジスタを表示するときに (gdb) info register rax # もしくは i r rax としていたが、レジスタは変数としても参照可能なことを知った。頭に $ をつけるだけ。 (gdb) print/x $rax 変数として参照できるので、操作の度に自動でレジスタを表示する display コマンドを設定する事が可能。 (gdb) display $rax また register をポインタに cast してごにょごにょとかも可能。 (gdb) print/x ((intptr_t*)$rax)[1] $1 = 0x415a2c .gdbinit # http://0xcc.net/blog/archives/000126.html set history save on set history size 10000 set history filename ~/.
アセンブリ読んだら負けかなと思ってる - 誰かの役に立てばいいブログ
子供のころからできるだけ手抜きして成果を挙げることだけは長けている山本です。 今回は、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,
川o・-・）＜2nd life
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
WordPress 開発に便利なプラグイン Debug Bar - dogmap.jp
WordPress 3.1 から導入された管理バー。 僕は好きなんだけど、結構嫌いな人は多いみたいですね。 そんな人達に管理バーがあると便利だよって伝えたいエントリ。 まずは、以下の2つのプラグインをインストールしてみてください。 Debug Bar Debug Bar Console そうすると、管理バーの右端に「Debug」ってメニューが追加されるはずです。 これが相当便利。 wp-config.php に以下の3行を追加することで、このプラグインは真価を発揮します。 define('SAVEQUERIES', true); define('WP_DEBUG', true); define('WP_DEBUG_DISPLAY', false); デバッグ作業終了後は、これらはコメントアウトしておいたほうが良いでしょう。 Deprecated というメニューを選択すると、WordPres
WordPressのいろいろなデバッグ方法
WordPressをカスタマイズしていると、何かとエラーが出たりします。 その際によくあるデバッグ方法として、config.phpへの記述に define('WP_DEBUG', true); と記述し、エラーを表示させる機能があります。 ちなみにこれ、エラー表示を抑制するかしないかの機能。 もっと詳しく言うと、wp-admin/plugins.phpの140行目あたり、 if ( ! WP_DEBUG ) { error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR ); } こんな記述があったりします。 でも、WP_DEBUGをtrueにしても、
WordPressチューニング、その前に使うDebug Bar | さくらのナレッジ
WordPressは非常にポピュラーなソフトウェアです。非常に多くのサイトで使われており、この「さくらのナレッジ」もWordPressをベースに作られています。 WordPressはPHPのコードとApache等のWebサーバ、mySQL等のDBサーバで構成されています。インストールは比較的簡単ですぐに始められるのですが、WordPress自体が大きなプログラムであるのに加え、多数のプラグインやテーマが流通しているため、どんどん機能を追加するうちにサイトが重くなっていき、見るに堪えないページができあがってしまうこともしばしばです。そのためか、WordPressのチューニング方法を取り上げた記事はとても多く、どれも人気があります。ただ、それらの記事で紹介されている手法が、本当に自分のサイトを速くしてくれるのだろうかと、疑問に思ったことはないでしょうか。チューニングの基本はまず測定です。そこで
WordPressテーマ開発向けプラグインを一式管理するプラグイン・Developer - かちびと.net
WordPressを提供するAutomattic社が 先日リリースした、テーマ開発者 向けのプラグインを一括管理できる プラグイン、Developerのご紹介。 とくに特別な機能は無いです。 WordPressのプラグインの中には様々なテーマ開発補助のプラグインが存在します。その中で、Automattic社が選定して一括管理出来る様にしたプラグインがDeveloperです。 デバッグとかテストツールとか、WordPressのテーマ開発によく使われる補助プラグインをインストールできる等、一式管理できる、というプラグイン。 管理できるプラグインは以下の通り。 Debug Bar Debug Bar Cron Rewrite Rules Inspector Log Deprecated Notices VIP Scanner Monster Widget Beta Tester スクリーンショッ
WordPressのwp-config.phpで出来る事いろいろ - かちびと.net
自分用メモ。wp-config.phpの設定 で出来る事のリストです。よくある カスタマイズは、テーマファイル内 にコードを書きますが、wp-config で出来る事を知っておくのもとても 大事ですね。 普段あまり利用しないので覚えてないし、困ったときはいちいち探してるので時間をロスしないようにメモしておきます。 スニペットのメモリストですし、細かい解説は面倒なんでしません。また、「wp-configってなんだろう？」という方には全くお役に立てないと思います。 wp-config.phpで出来る事リスト 以下リストです。古いバージョンの事は視野に入れてません。 リストはCODEXのwp-config.phpの編集から抜粋しています。 ※変更前にバックアップして下さい ※自己責任でお願いします ※コード一覧は記事最下部に有ります 01. デバッグモードにする define('WP_DEBUG
PHPは代入と参照の違い | 2013-03-07 - bravewood の日記
http://ameblo.jp/nikko-inma/entry-11122429825.html http://b.hatena.ne.jp/entry/ameblo.jp/nikko-inma/entry-11122429825.html ふむふむ、なになに、PHPはクソ言語で、C++もVBもクソで、 きっちり書きたいときはC きっちり書きたいときはC きっちり書きたいときはCイスから転げ落ちるわ！！！ ちょっとこれはPHPerとしては突っ込まざるを得ない。 いつ突っ込むかって？ 今でしょ！！ とりあえず上記サイトで書かれてるサンプルじゃあ代入と参照が深く理解できないだろうってこともあり、その部分補足してみよう。 まずサンプルプログラム <?php $a = 1; xdebug_debug_zval( 'a' ); $b = $a; //これはただの値の代入（ただしこので時点でbの変
WordPressのWP_DEBUGによるPHPのエラーをファイルに出力する方法
WordPressでエラーが起きているときにwp-config.phpのWP_DEBUG定義をtrueにするとエラーがページに出力されてしまうため、実運用しているサーバではWP_DEBUGをtrueにしづらい。そこでページ内ではなく外部ファイルにエラーを出力できないものかと考えた。 WordPress内部ではエラーの出力にerror_logを使っているだけなので、出力先はphp.iniによって設定を変えることで可能である。レンタルサーバなどではphp本体の設定は変更できないのでini_setなどを使って、動的に設定を変更することになる。 実はWordPressはこの要求を設定で満たすことができて、 ini_set('display_errors', 0); define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_
jQuery 1.9 のソースマップ対応で圧縮版でもデバッグが簡単になった話
jQuery 1.9 がリリースされました。1.9 の新機能の中ではあまり注目されていませんが、ソースマップに対応したのが地味に便利そうです。 というのも、圧縮版の jquery.min.js を使っていると 何か問題が起きたときにスタックトレースを眺めても jQuery の部分が意味不明 デバッガーで jQuery のソースにステップインしても意味不明 といった理由で、開発中には非圧縮の jquery.js を使うことが多かったわけです。 それが、1.9 からはソースマップに対応したので圧縮版のままでのデバッグが簡単になってます。 超簡単な使い方 ソースマップに対応したブラウザーは現時点では Google Chrome のみなので、Google Chrome の手順を説明します。 (Firefox はソースマップへの対応を計画中らしい) 事前準備を忘れずに Google Chrome で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chromeでjavascriptデバッグ！まず半歩♪