第 5 章 たすけてくれ〜〜ぃ!!!!

目次
5.1. 全般的なお助け事項
5.2. コンパイル特有の問題
5.3. 実行したときの問題

 あらゆる指示に一字一句たがわずしたがったとしても、ときどき予想もしなかったような問題に出くわすことはある。トラブルの原因はいくらでもあって、指示の読みまちがいから、そのソフトのバグ、別のソフトのバグまでいろいろ。ここでは、みんなが GNOME をいじって出くわした問題を採りあげてみよう。

5.1. 全般的なお助け事項

 まずは、しょっちゅう出てくる全般的な質問からいこう。個別の問題についてはこの章のあとのほうにある。

5.1.1. なんか動かないよ、わけわかんないよ、どうしよう?

 はいはい、まずなによりも先に、手を止めて、気を鎮めて、ぐっと深呼吸してね。それから、この FAQ と、ユーザガイドと、その他手元にあるドキュメンテーションを一通り見て、なんか問題解決に少しでも役にたちそうなことが書いてないかを見ておくれ。続いて、メーリングリストのアーカイヴを調べて(やりかたは前に説明したね)ほかの人が同じような問題の話をしていないか見てみよう。そして最後に、さっきまで自分がやっていたことをもう一回繰り返してみて、あっさり問題が解決してないかどうかを確認しよう。これが全部ダメだったら、やっとリストに質問を出す頃合いだ。

 まずそもそも、 gnome-list に入ってる、よね? 入ってないなら、どうすればいいかは前に説明した。で、 GNOME-list で質問するときには、詳しい情報をいっぱいつけること。「パネルがおかしくて、もうホント頭にきてるんですけど」なんてのでは、あなたにもわれわれにも役にたたない。そっちは問題を抱えたままだし、こっちはバグの可能性があるのになにも情報がわからない。もう少しましなのが「足あとメニューからhogeを選ぶと、いきなりパネルが消えるんですけど、どうしたんでしょう。それと、GNOME がホームディレクトリに core ってのをしょっちゅうつくるんですけど、このファイルはなんですか?」くらいだけれど、これでも不十分だ。

 理想的には、いくつか出してほしい情報がある。まず、そもそもどんなシステムを使っておるの? いやいや、みんながあなたと同じ OS を使っているとは限らない。 CPU の種類がいる。 Sparc, MIPS, i386 (これには Pentium, AMD, Cyrix なんかも含まれる), PPC, Alpha, ARM, 680x0, 等々。さらには OS の種類がいる。 Linux ディストリビューション、 FreeBSD, HURD, OpenBSD, Solaris, IRIX, CrayOS, OS/400 等々。さらに、その OS のバージョンも忘れずに。たとえば、いまぼくが使っている OS は、 GNU/Linux RedHat/i386 Rawhide マシンで、ともだちは Solaris Sparc 2.6 マシンを使ってる。

 さらに、システム上の関係あるいろんな数字もいるな。 GNU/Linux システムでは、カーネルと libc のバージョンはほぼ確実に必要だ。GNOME がらみの問題では、ほとんどすべての場合に glib, gtk+, Imlib, ORBit, gnome-libs のバージョンが必要になる。どれが関係してるかわからなかったら、とにかく全部つけておこう。ときどき関係してくるのが Perl, X11, Python, Guile, libpng のバージョンだけれど、エラーメッセージにこういう名前が見あたらなければ、これは入れなくていい。それと大事なのが、どうやって GNOME をインストールしたか。バイナリを使ったの? その場合はどのバイナリ? tarball を使った? CVS を使ったんなら、何日づけで、あるいはタグは? 以上を組み合わせてるなら、どうしたのか教えてほしい。

 そしてやっとやっと、問題そのものだ。まず、具体的にどうやるとその問題が起きるのか教えてほしい。その問題が必ず起きるのか、時々だけなのかも知りたい。問題が起きる前に、なにかメッセージとか出していたら、それも。そしてその問題に出くわしたときに、ずばりなにが起きるの? もしやる気があるなら、ぼくが以下に説明する診断ツールも試してみて。たとえば backtrace とかして、その情報をメールにつけること。

 これで質問をポストする準備ができた。ここできみは、有効な subject 行を考えなきゃならない。 Gnome-list にはメッセージがたくさん載るので、助けてくれそうな人がちゃんと目に留めて、助けられない人たちがちゃんと捨てられるような見出しにしておきたいもの。「GNOME が変です」だとたぶん見過ごされる。「GSM は使いものにならない」だと、みんな助けるより先に怒っちゃうだろう。「HP-UX でパネルのアイコンがみんな黒い四角になってるんです」みたいな感じだと、それなりの反応が得られるはず。

 以上をまとめて長い電子メールをしたためよう。そしてリストにポストする。ぼくのアドバイス通りにしていれば、たぶんすぐに、役に立つ返事がもらえるはず。すぐにこなくても、怒ったり落ち込んだりしないように。たぶんメールの洪水に埋もれて見逃されたんだろう。何日か待ってみて、もうちょっと詳しい説明がつけられないか考えて、あるいは見出しをもっとわかりやすくしたりして、もう一度ポストしてみよう。

5.1.2. バグの報告はどうするの?

 バグを見つけたら、教えてほしい。ちゃんと追いかけてなおしたいから。このプロセスをできるだけ効率的にするために、ぼくたちは Debian のすぐれたバグ追跡システムを拝借した。この使い方のすべては http://bugs.gnome.org/Reporting.html に説明してある。

 このシステムにバグ報告を送るとき、いくつか頭に入れておくべきこと。まず、http://bugs.gnome.org の web フロントエンドをちゃんと調べて、そのバグがもう報告済みじゃないかどうか確認するように。もし報告されていない新しいバグなら、それを submit@bugs.gnome.org に送ってほしい。

 指示にあるように、パッケージやバージョンのヘッダを入れるようにしてほしい。そうすれば、しかるべき人たちに、すばやく自動的に振り分けられるから。細かいところを詳しく記述しよう。どういう情報を入れるべきかは、この前のところを見てほしい。 backtrace や strace があったほうがよければ、是非ともいれてほしい。このやりかたも下に説明してある。

 バグをシステムに登録したら、それについてのフィードバックが電子メールでくるはず。あと、そのバグの状況について、web フロントエンドで追跡もできる。

5.1.3. prefix (または $prefix, ${PREFIX}, または <prefix>) ってなに?

 GNOME がコンパイルされるとき、それをファイルシステムのどこに置くかを指定しなきゃならない。これを指定するためのオプションが --prefix だ。だからぼくたちはこれを GNOME Prefix、略して prefix と呼ぶ。 GNOME のファイルの位置は、prefix 以外ではどのシステムも同じになってるはずだから、あるシステムで /usr/share/gnome/pixmaps にあるファイルは、別のシステムでは /opt/gnome/share/gnome/pixmaps になってるかもしれない。ぼくたちはこれを記述するのに $prefix/share/gnome/pixmapsと書くわけ。

 もしtarball (または CVS) からインストールしたけれど、 configure (または autogen.sh) で prefix を指定しなかった場合、デフォルトは /usr/local になっている。 RedHat RPMS を使ってるなら、かれらの使う prefix は /usr だ。もしどうしてもわからないなら、 which panel とタイプしてほしい。出てきたもののケツの/bin/panel を取ると、残ったものが prefix だよ。

5.1.4. Segmentation Fault ってどういう意味?

 ほとんどの Unix や Unix 系システムには、メモリ保護という機能がある。どういうことかというと、プログラムはメモリの一部だけ(これがセグメント)にアクセスできて、それ以外のところには手を出せないようになってるということだ。もしそのプログラムが自分に認められたセグメント以外のメモリにアクセスしようとすると、システムは、これはいかんということで、エラーを出す。これが Segmentation Fault (一部のシステムでは略して “segv” ), で、ふつうそのソフトはすぐに異常終了し、あとにコアダンプ(下を見てね)を残す。

 結局のところこれは、きみの使ってたソフトのどこかにバグがあったということだ。それは GNOME のソースコードのバグかもしれないし、そのプログラムの共有ライブラリのバグかもしれないし、コンパイルがまずくて起きたバグかもしれない。もしそれが GNOME のバグかそれ以外のバグなのかがわからなければ、リストできいてみよう。もしそれが GNOME のバグだと確信できるなら、是非ともバグ追跡システムにのっけてね。

5.1.5. コアダンプ(core dump)ってなに? しょっちゅう core ってファイルを見かけるけど、これは何なの?

 むかしむかし、電子計算機の草創期には、コンピュータのメモリは磁気リングの集まりで、これがコアというものだった。これを電線の網にくっつけておくわけ。プログラマがプログラムでなにがどうなってるか知りたければ、コアメモリの中身を出力させて、それを分析したわけだ。この出力がコアダンプで、コアメモリなんか使われなくなった今日でも、この用語だけは残ってるんだ。

 各種の Unix や Unix 系システムでは、プログラムが異常なかたちでへたると(たとえば上で説明したような Segmentation Fault を起こすと、コアダンプを core というファイルにして、プログラムを実行していたディレクトリに出力する(訳注:日本語では、これは「プログラムがコアを吐いて死ぬ」と表現されることが多い)。このファイルは、なぜプログラムが死んだのかをデバッグするときにとても便利で、backtrace (下を見てね)をつくるのにも使える。一方で、このファイルはかなりでかかったりする。特にデバッグで使うつもりがなければじゃまなだけだ。コアを吐いてもらわなくていいなら、システムのドキュメンテーションを見ると、これを出さないようにする方法が書いてあるはずだ。

5.1.6. backtrace ってなにかしら? backtrace を送れといわれたんだけれど、どうすればいいの?

 異様に便利なデバッグツールが backtrace だ。これは要するに、プログラムのどこにいるかをスナップショットで記録してくれるものだ。これはプログラムがクラッシュするとき(つまり segmentation fault みたいなエラーで異常終了したとき)や、ハングしたとき(異常終了はしないけれど止まったり凍ったりするとき)にいちばんよく使われる。ここの説明では、 GNU プロジェクトの GDB デバッガを使うものと仮定する。これがいちばんよく使われているし、ぼくが使ってるものでもあるからだ。ほかのデバッガを使っているなら、そのドキュメンテーションにあたってね。

 backtrace をかけるには大きく二種類のやりかたがある。プログラムが死んだときに吐いたコアを使うか、あるいはデバッガの中でプログラムを走らせるかだ。ぼくは、デバッガの中でプログラムを走らせるほうが信頼性が高いと思うけれど、core を使う場合も説明しよう。

 GDB のなかでプログラムを走らせるには、 xterm (または kterm や rxvt など相当品)をたちあげて、こうタイプする。gdb <プログラムのフルネームと位置>。たとえば、gtalk をデバッグする場合にはこんな感じだ。 gdb /usr/local/bin/gtalk。 GDB はパスを観てくれないから、プログラムがどこにあるかは自分で指定すること。もし引数をつけてプログラムを実行したい場合でも、 ここではつけちゃダメだ。コマンド状の引数はあとで指定できる。

 すると GDB の起動メッセージが出て、(gdb) というプロンプトを出す。ここからrun とうつとプログラムが走り出す。引数をつけてプログラムを実行したければ、ここで引数を渡そう。たとえば、 gtalk のサウンドをオフにしてデバッグしたいときには、こんな感じだ。run --disable-sound。プログラムが実行を始める。ふつうより実行は遅くなるし、使うメモリもずっと多くなることは忘れずに。

 では、問題を再現してみよう。前にその問題を起こしたことをやってみてほしい。プログラムがクラッシュしたら、すぐにデバッグセッションでなにか出てくるはず。そして (gdb) プロンプトがあらわれる。プログラムがハングしたら、それが完全に、いつものところでハングして止まったと確信できるまで待って、それからデバッグセッションで Control-C を押す。これまた、いろんなメッセージを返してきて、(gdb) プロンプトが出てくるはずだ。どっちの場合でも、このプロンプトが出てきたら bt とタイプする。するとデバッガが、実際の backtrace を吐き出す。

 以下にデバッグセッションの実例を示しておこう。 backtrace を送れといわれたら、以下をまるごと送ればいい。

$ gdb /usr/local/bin/gtalk
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run --disable-sound
Starting program: /usr/local/bin/gtalk --disable-sound

Program received signal SIGINT, Interrupt.
0x4049290d in __poll (fds=0x808c110, nfds=3, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:45
../sysdeps/unix/sysv/linux/poll.c:45: No such file or directory.
(gdb) bt
#0  0x4049290d in __poll (fds=0x808c110, nfds=3, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:45
#1  0x403c54e9 in g_main_poll (timeout=-1, use_priority=0, priority=0)
    at gmain.c:991
#2  0x403c516e in g_main_iterate (block=1, dispatch=1) at gmain.c:789
#3  0x403c58a1 in g_main_run (loop=0x80882e8) at gmain.c:912
#4  0x401cbf1d in gtk_main () at gtkmain.c:475
#5  0x804a629 in main (argc=2, argv=0xbffffaa4) at main.c:54
#6  0x40407c77 in __libc_start_main (main=0x804a570 <main>, argc=2, 
    argv=0xbffffaa4, init=0x8049e10 <_init>, fini=0x804c7dc <_fini>, 
    rtld_fini=0x40009c10 <_dl_fini>, stack_end=0xbffffa9c)
    at ../sysdeps/generic/libc-start.c:78
(gdb)

 コアダンプで backtrace をするのもほとんど同じだ。コアダンプの core ファイルのあるところにディレクトリを変えて、 gdb -c core <full name and location of program> を実行する。ここでも GDB はパスを観てくれないので、プログラムの実際のありかをちゃんと指定してやること。あとはもうプロンプトで bt と売って、セッションをまるごと送ればいい。

5.1.7. strace ってなにかしら? strace を送れといわれたんだけれど、どうすればいいの?

 strace コマンドはプログラムを実行しつつ、システムコールや信号を出力していくソフトだ。これは backtrace よりかなり「その場」用のデバッグツールなんだけれど、ときには strace で出てくる追加の情報がいるときもあるんだ。 strace を出すのは簡単だ。単に xterm で strace -o <output file> <引数をつけたコマンド> と打てばいい。たとえば、サウンドをはずした gtalk に strace をかけたければ、こんな感じだ:strace -o /tmp/gtalk.strace gtalk --disable-sound。これで strace 出力が /tmp/gtalk.strace にできる。strace はパスをみてくれるし、起動時のコマンドラインでの引数も受け付ける。

警告: strace の出力はすごく大きくなる。上の strace の例だと、5 秒で 5,498 行が出力された。だから straces はメーリングリストには流さないでほしい。開発者がどうしても送れという場合に限って、その人に送ってあげること。