Linuxカーネルをgdbでデバッグ（またはディストリビューションのカーネルを使うときは当たってるパッチにも注意しよう） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
Linux:パフォーマンスに影響あるデバッグオプションがどれだけ影響あるか試してみた - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
なんとなくやってみた系ですね。 今回はCONFIG_DEBUG_OBJECTSのところです。 CONFIG_DEBUG_OBJECTS_FREEがkmalloc/kfreeをヘヴィにつかうような場合にパフォーマンス劣化するよーなんていってます。 まずはCONFIG_DEBUG_OBJECTSの項目を全部無効にした場合。 この時点でもロック周りに時間取ってますね。 hackbenchを引数 10 process 20000 で実行してる時の様子がこんな感じです。 次にCONFIG_DEBUG_OBJECTSの項目を全部無効にした場合。 起動した時点でかなりの時間をロックで使ってます。 そして、hackbenchを同じく実行するとこうこうなります／(^o^)＼ このときはこんな感じになっていてもうどうにもならない感がありますね。 説明に書いてあるとおり、ほんと遅くなりますね。 ( ´ー｀)ﾌｩ
Linuxのsystem call fuzzer「syzkaller」めも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxのシステムコールのファジングツールとしてsyzkallerというのがあって、これはコードカバレッジを見つつ入力を変えていってくれるというファジングするツールです。 試してみたのでどんな感じなのかを簡単にめも。 まず、ツール自体はgolangで書かれているのでgoの実行環境が必要です。あとテスト対象のカーネル側でコードカバレッジを利用可能になっている必要があります。この辺はsyzkallerのドキュメントに書かれています。 ツールはビルドして行います。make一発で良いのですが、デフォルトだとstatic linkなバイナリを作ります。うちだと-lpthreadと-lcのところでそんなライブラリはないとか怒られてしまったので、動的リンクにしました。ホストとゲストのディストリビューションが同じならライブラリのABIの違いとかないですし、これで良いでしょう。 ファジングはVMを使って行
はじめてのgdbデバッグ | blog: takahiro okumura
仕事でagを利用していた時に出会ったバグを、先輩たちの力を借りてなんとかした話です。 先に結論を書くと、業務に用いていたagのバージョンが古いのが原因のようでした。version 0.15より古いとlockの実装に問題があるようです。 以下、問題の発覚からなんとかするまでの記録です。 発端 agが途中で止まる 時折、agのファイル操作が先へ進まなくなってしまう不具合がありました。 操作中に対象ファイルのロック状況が変わるとデッドロックが発生しているのでは？と想像。 気になってstraceでプロセスにアタッチすると、以下で停止していることが分かりました。 [pid 4589] futex(0x80517e4, FUTEX_WAIT, 32159, NULL FUTEX_WAIT futex(2)を引くと、futex(2)の書式に対する操作FUTEX_WAITの説明があります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
