SGI KDBを使ったカーネルデバッグスレ

カーネルデバッグの話はここで存分にどうぞ

age

1.http://oss.sgi.com/projects/kdb/ より、使用しているカーネルにあった
　パッチをダウンロードし、カーネルソースにパッチを当てる。
2.make xconfigなりのカーネルコンフィグアプリを起動。
　Kernel Hackingの項目が追加されているので、
　"Build-in Kernel Debugger support"をyにする。ついでに
　"compile the kernel with frame pointers"もyにしたほうがスタック
　トレースがとりやすくなる。
3.カーネル再構築。
4.lilo.confに以下のように"kdb=on"のカーネルブートオプションをつける。
>image=/boot/vmlinuz-2.4.4-test
> label=test
> read-only
> root=/dev/hda2
> append="kdb=on"
5.liloを実行し、ブート情報を書き込み、ブートオプションをつけたカーネルから
　ブート。
6.Pauseキーを押すとカーネルデバッガに入る。"g"コマンドで再開。

リモートの場合。
1.同じくクロスシリアルケーブルを用意しターゲットとターミナルを繋ぐ。
2.ターミナルマシン上で適当なターミナルプログラムを起動する。
3.liloのappendコマンドを以下のように変更。
　append="kdb=on console=ttyS0,38400"
　これで、シリアルコンソールにデバッガの出力が表示される。
　停止はターゲットでPauseキーか、ターミナルでCTRL-A。
4.ただこれだと、ブートメッセージがターミナルにしか表示されなく
　なるので、以下のようにしたほうがいいかも。
　append="kdb=on console=ttyS0,38400 console=tty0"
　これで、ブートメッセージは両方に出力される。そのかわりCTRL-Aでの
　Breakinはできなくなる。
　Initは最後に指定されたコンソールに出力するらしく、
　append="kdb=on console=tty0 console=ttyS0,38400"
　のようにしてしまうとInitの出力がターミナルだけになってしまうため
　不便。

とりあえず、Linuxカーネルのなかで実際に止めてみて、どんな感じになるか見てみよう。
えっと、とりあえずSGI KDBは動いてるとします。で、なんかユーザーが特定の
操作をやったらとまる場所を探そう。俺が今回使うのはipv4のicmpのコード。
ユーザーがping叩けばそこ必ずとおるからね。普段はあまり通らないから変に
たくさん止まることもないと。
ソースをみていい止める関数を探してもいいが、今回俺はsystem.mapを使った。
system.mapをエディタで開いてみるとこんな感じでicmpがらみの関数がある。
c0206a60 t icmp_reply
c0206be0 T icmp_send
c0206f60 t icmp_unreach
c0207220 t icmp_redirect
c02072d0 t icmp_echo
c0207320 t icmp_timestamp
c0207410 t icmp_address
c0207420 t icmp_address_reply
c0207570 t icmp_discard
c0207580 T icmp_rcv
icmp_unreachなんかがいいかね。多分icmpが届かなかった場合にくるファンクション
だろう。はい、ターゲットマシンでPauseキーを押してbreakinしましょう。
[1]kdb>　とかいうプロンプトがでるな。最初の数字はプロセッサナンバーだ。
シングルプロセッサで動かしてるなら常に0になる。
で、icmp_unreachにbreakpoint張るわけだが、system.mapを見て
[1]kdb> bp c0206f60　とじかにアドレス指定してもいいんだが、もっと簡単に
[1]kdb> bp icmp_unreach　とシンボルを指定してもできる。
うまくbreakpoint張れたら
Instruction(i) BP #0 at 0xc0206f60 (icmp_unreach)
is enabled globally adjust 1
とか出るはず。あと、とりあえず、breakpoint張る前に実際のそのアドレスが
ファンクションの先頭であるか確認したほうがいいな。
ディスアセンブルはidコマンドだ。
[1]kdb> id icmp_unreach
0xc0206f60 icmp_unreachpush %ebp
0xc0206f61 icmp_unreach+0x1mov %esp,%ebp
0xc0206f63 icmp_unreach+0x3mov $0x14,%eax
0xc0206f68 icmp_unreach+0x8push %edi
0xc0206f69 icmp_unreach+0x9push %esi
0xc0206f6a icmp_unreach+0xapush %ebx
こんな風に先頭2インストラクションが push %ebpとpush %esp,%ebp　ならそれは
まず間違いなく関数の先頭だ。これはC言語のStackFramを作るコードだ。

breakpointが張れたらgコマンドで再開。icmp_unreach関数を呼ぶために
適当な存在しないipアドレスへpingを送ってみよう。
breakpointにHitしたら
Instruction(i) breakpoint #0 at 0xc0206f60 (adjusted)
0xc0206f60 icmp_unreachint3
Entering kdb (current=0xc1228000, pid 0) on processor 1 due to Breakpoint @ 0xc0206f60
のようなメッセージが出てコマンド待ちになる。
なにはともかく。止まったらスタックバックトレースを取ろう。コマンドはbtだ。
[1]kdb> bt
EBP EIP Function(args)
0xc1229e5c 0xc0206f60 icmp_unreach (0xc01051b0, 0xffffe000, 0xc1228000, 0xc1228000, 0xc1228000)
kernel .text 0xc0100000 0xc0206f60 0xc0207220
0xc0106fac ret_from_intr
kernel .text 0xc0100000 0xc0106fac 0xc0106fcc
Interrupt registers:
eax = 0x00000000 ebx = 0xc01051b0 ecx = 0xffffe000 edx = 0xc1228000
esi = 0xc1228000 edi = 0xc1228000 esp = 0xc1229fac eip = 0xc01051df
ebp = 0xc1229fac xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000246
xds = 0xc1220018 xes = 0xc1220018 origeax = 0xffffff00 ®s = 0xc1229f78
0xc01051df default_idle+0x2f
kernel .text 0xc0100000 0xc01051b0 0xc01051f0
0xc1229fc0 0xc0105272 cpu_idle+0x52
kernel .text 0xc0100000 0xc0105220 0xc0105290
うーん、なんかうまく取れてないね。StackFrameがちゃんと作られてないと
完全には取れないんだね。でも関数の頭を見る限り全部StackFrameは
作られてるんだけどね。謎だ。KDBのソースを見て調べてみるしかないね。

うまくスタックトレースが取れないから、ssコマンドを使ってトレースを
しながら、breakpointをうまく張って上位の関数に戻っていくと、
ip_rcv->icmp_unreachと来ていることがわかる。さらにトレースすると、以下の
トレースが取れるようになる。
#[1]kdb> bt
# EBP EIP Function(args)
#0xc1229e74 0xc01e92bf ip_run_ipprot+0x3f (0xc191fb60, 0xc76cdc70, 0xc030e108, 0x1, 0x1)
# kernel .text 0xc0100000 0xc01e9280 0xc01e92e0
#0xc1229eac 0xc01e93f6 ip_local_deliver+0x116 (0xc01051b0, 0xffffe000, 0xc1228000, 0xc1228000, 0xc1228000)
# kernel .text 0xc0100000 0xc01e92e0 0xc01e9460
# 0xc0106fac ret_from_intr
# kernel .text 0xc0100000 0xc0106fac 0xc0106fcc
#Interrupt registers:
#eax = 0x00000000 ebx = 0xc01051b0 ecx = 0xffffe000 edx = 0xc1228000
#esi = 0xc1228000 edi = 0xc1228000 esp = 0xc1229fac eip = 0xc01051df
#ebp = 0xc1229fac xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000246
#xds = 0xc1220018 xes = 0xc1220018 origeax = 0xffffff00 ®s = 0xc1229f78
# 0xc01051df default_idle+0x2f
# kernel .text 0xc0100000 0xc01051b0 0xc01051f0
#0xc1229fc0 0xc0105272 cpu_idle+0x52
# kernel .text 0xc0100000 0xc0105220 0xc0105290
これで、大体のコードの流れがわかる。

ちょっとレジスタをいじって、不正処理を起こしてみよう。
とりあえず、bc *　コマンドで設定した全てのbreakpointを消して、再実行。
で、pingコマンドを終了。しばらくまってicmpの処理が終わったのを待って、
icmp_unreachに再度breakpointを設定。ping実行。ssコマンドを使って
icmp_unreach+0x18までステップトレース。次の命令はこの命令のはず。
0xc0206f78 icmp_unreach+0x18mov 0x5c(%edx),%ebx
これで、edxに0を入れれば当然不正処理が起きる。rm edx 0 でedxに0が入る。
確認はrdコマンドで出来る。edxに0が入ったことが分かったらgコマンドで再実行。
[0]kdb> g
Unable to handle kernel NULL pointer dereference at virtual address 0000005c
printing eip:
c0206f78
*pde = 00000000

Entering kdb (current=0xc0312000, pid 0) on processor 0 Oops: Oops
due to oops @ 0xc0206f78
eax = 0x00000014 ebx = 0xc226d0a0 ecx = 0x00000008 edx = 0x00000000
esi = 0xc1aeaea4 edi = 0xc7536c00 esp = 0xc0313e30 eip = 0xc0206f78
ebp = 0xc0313e58 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc0313dfc
のようなメッセージを出して止まるはず。メッセージより、0xc0206f78のコードが
0x5c番地をアクセスして不正処理で止まったことがわかる。[0]kdb> id %eip とすれば
0xc0206f78 icmp_unreach+0x18mov 0x5c(%edx),%ebx
とでるから、edx=0が原因となったことがわかる。

あとは俺は基本的にsage進行。オリジナルスレは適当にうっちゃってsage out
させてくれ。

○岡さん？>>別スレ１

俺は自分のwebページも持ってない、しがない一プログラマです。だから誰も
知らないでしょう。

kernel毎刺さってるときって、どうデバッグすればいい?
再現出来ないときがほとんどだし、めったにでないけど。
ダンプとかってとれるのかな。

>>1
うにゅースマソ
ほとんど同じ草稿を見たことあったもんだから、勘違いした

KDBがonになっていれば、コードが無限ループになっている場合は普通に
pauseキーでbreakinすれば回ってる場所で止まるはず。マルチプロセッサに
すれば、確実に止まるね。cpu 0が無限ループしてもcpu 1がbreakinの処理を
行えるから。
コードが無限ループしているわけじゃなくてシンクロナイズリソースで止まって
る場合はちょっと面倒。多分btaで全プロセスのスタックを取って怪しいリソースを
見つけてそれの待ち行列リストからたぐっていくしかないんじゃないかな。

ダンプを取れるカーネルは同じくSGIが提供してる。使ったこと無いけど。
基本的にダンプがあっても、そうとう運がよくないとトラブルシュートできない
からね。下手にダンプがあると、素人さんが「ダンプがあるからなんでもできるだろ」
と思い込むから危険。すでに稼動しているシステムだとかなり難しいんだけど、
それでもライブでデバッグできるような状況にもっていくのが重要かな。

前スレ
「Linux版に立てるWin2Kトラブルシュートスレッド」
http://cocoa.2ch.net/test/read.cgi?bbs=linux&key=989048022

>>14
なるほど。サンクス。

結局1はどうしたいのさ？
2chでお山の大将になりたいの？まあそれにさえ失敗してるけどね。
MLへ行くなりKernel Debug Mini-HOWTO書くなりした方が尊敬されると思うよ。
まあここが1がやっと見つけた居場所なら何も言わないけどな。
いろんなスレで叩かれたり相手にされなくなったりしたみたいだから。

>>17
君、つまらんよ。

うーん、どうやっても煽られるのね。みなまで書かんとわからんか。
前のスレを立てた動機はこの板で「Win2Kは落ちる」だと書かれることが
多いから、真実を知るために立てた。Win板やUNIX板に立てなかったのは
それらの板では落ちるなどということは書かれることが殆どなかったからだ。
その後Linux専用で立てろという意見があり、誰かが新スレを立てれば俺は
そっちに移ると言った。そしたら誰かが新スレを立てたから言った通り俺は
ここに移ってきて、Linux専用の内容をここにコピペしたまでだ。
お呼びでないなら、適当にうっちゃってsageてくれ。

うん、1の言う事は間違ってない。
Win2Kは落ちるとろくに使ってもない奴がいうのは間違い。
まあ、それでもいろんなとこで落ちるとか不具合の話を
聞くのは何故だか知らないが(藁
しかし、素直に1の技術力には感心するな、

1=別スレの1=18

>>21
ぶー、ハズレ。

age

これはあげよう

1=別スレの1=18=20=22

めっちゃわかりやすい。

さすが妄想力。おみそれしました。