誰得な内容ですので簡潔に。 #include "Zend/zend_interfaces.h" // (略) zval *zp; // (中略、この間にzpに意味のある値が入ったとする) // zpの型が何だろうと綺麗に表示! zend_call_method_with_1_params(NULL, NULL, NULL, "var_dump", NULL, zp); Z_LVAL_PとかZ_STRVAL_Pとかを使い分けずに済むので楽チンです。
前回: PHPソースコードリーディング入門(とっかかり編) - id:anatooのブログ PHPのソースコードを読んでいく際に、どうしてもソースコードを読むだけではよくわからない部分というのが出てくる。この記事ではPHPをデバッガで動かして内部の働きを明らかにする方法を書く。 ソースコードの取得 gitから取ってくる。 $ git clone https://github.com/php/php-src.git デバッガで動かせるようにビルドする 余計な拡張は無しで、デバッガで動かせるようにビルドする。configure時に--enable-debugオプションを渡す。 $ cd php-src $ ./buildconf $ ./configure --disable-all --enable-debug $ make GDBで動かす makeした後、コマンドラインで動かせるバイナリは
PHPのソースコードを読むためのとっかかりの話。 ソースコード取ってくる gitから取得できる。 $ git clone https://github.com/php/php-src.git とりあえずビルドしてみる ビルドに必要なツールをインストールした後、buildconfスクリプトを叩いてconfigureスクリプトを生成したのち、通常通りconfigureを叩いてmakeする。例えば、余計な拡張を一切ビルドせずデバッガで動かせるようにビルドしたい場合は以下のようになる。 $ cd php-src $ ./buildconf $ ./configure --disable-all --enable-debug $ makeコマンドラインから叩けるバイナリは、"sapi/cli/php"にある。 $ sapi/cli/php -r "echo 'hello world';" hello
php-tokyo tyrant を利用して、ディフォルトのままでsession.save_handler = tokyo_tyrant ととすると、Segmentation fault がおきる問題があったので書いてみる。 環境構築 tokyo tyrant をインストールする インストールの前に、checkinstallというソフトを利用すると、パッケージを自動で作ってくれて便利です。 まずはこれを導入します。 checkinstallでぐぐってrpm見つけてきてねw //centso系 or apt-get install checkinstall //debian系 //まずtokyo cabinetをインスコします。 cd wget http://1978th.net/tokyocabinet/tokyocabinet-1.4.43.tar.gz tar zxvf tokyoca
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
PHPプログラミングの際にコードをデバッグするのに最も手軽なのは、var_dumpやロガーで変数の中身を見る方法だと思う。例えば何やらおかしな動きをするメソッドがあった時に、その中のコードにvar_dumpを差し込んでコマンドラインで実行する。そして本来とるべき値から外れている変数や値を見つけることで、バグの原因を見つけるのに有用な情報を得ることができる。 このやり方は簡単だが問題がある。おかしな動きをするメソッドの中に、var_dump($a);というコードを挿入して、コマンドラインで実行して、$aという変数の中身を確認する。が、特に何もおかしなところがない。コードを書き換えて次は$bという変数の中身を見るが問題はない。次にコードを書き換えて$cという変数の中身を…という風に、おかしな値がなかなか見つからない時に var_dump等のコードを挿入する コマンドラインで実行する 表示された
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog おひさしぶりです。オークション担当の山崎 賢です。 前回はPHP Serialize についてでしたが、 今回はPHPでのデバッグに関してお話します。 基本PHPはインタプリタ(厳密にはPHPは内部で一度コンパイルしていますのでインタプリタとは言い切れませんが) のデバッグではログ埋め込みが手軽です。 しかし、まれにSIGSEGVやSIGBUSなどでPHPスクリプトが落ちることがあり、途方にくれます。 地道にログを埋め込んでいき、箇所を特定するのも手法の1つですが、今回はgdbを用いたデバッグ方法を記載したいと思います。 ■STEP1 まずは、プログラムが落ちることを目的として以下のようなPHP Moduleを作成します。 ・ ・
昨日の件ですが。 はてなブックマークでshimookaさんからは(嬉しい)励ましの言葉を頂いたり、heavenshellさんからは有益なURLを教えてもらったおかげなのかは分かりませんが、自分の中で「gdbの使い方を(より)理解してみよう!」というモチベーションが上がってきました。 熱しやすく冷めやすい性格なので、熱が冷めないうちに色々とやってみた。 ブレーク・ポイントはファイル(行)指定でも可能なんですね。これは知らなかった。。。 PHPが提供している関数は内部的には「zif_」というプレフィックスがつくのですが、こういうのが分からない時にザックリと(適当に)設定したい時に役に立ちそう。 「i_zend_is_true」関数ではなくて、ファイル(行)指定でブレーク・ポイントを設定して同じ結果になるか確認。 % cd $HOME/php-5.3-dev % gdb ./php-cli GN
先日の件ですが。 最後はprintfを盛大に仕込むという荒業で乗り切ったものの、今後も同じ作業を行い続けるのは効率が悪すぎるので、gdbを使って効率よく作業できないか。。。と探っていたところ、できるようです。しかも簡単に。_| ̄|○ とりあえず、前準備としてPHPバイナリを用意(--enable-debugオプション付きでビルド)。 % cd $HOME % mkdir ./php-5.3-dev % mkdir ./php-5.3-dev/work % cd ./php-5.3-dev/work % wget http://snaps.php.net/php5.3-200808250230.tar.gz % gzip -dc ./php5.3-200808250230.tar.gz | tar xvf - % cd ./php5.3-200808250230 % ./configure
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く