即使你逐字逐句地按照每一条指令去做，有时也会碰到一些不可预见的问题。 从看错一条指令，到软件本身的一个bug，或其他软件的瑕疵，什么都可能 导致失败。这里我们看一下人们在和GNOME打交道时遇到的一些问题。
下面是一些经常出现的一般性问题，专门性的问题在本章的后面介绍。
没事，你要做的第一件事是停下来，放松一下，做深呼吸。然后，看一遍这 个FAQ，用户手册，和你手头的其他文档，看是否能解决你的问题。最后，检 查Mailing List档案（这里告诉你如何去做） 看是否已经有人谈论过这个问题了．然后不管你做了什么， 再做一遍， 也许问题突然解决了．如果这些 都不起作用，你就该问Mailing List了．
首先，你已经订了gnome-list了，对吧？如果你还没有， 前面有关于如何订阅的介绍． 如果在GNOME-list上寻求帮助，尽量详细点． 发表类似"The panel doesn't work, this sucks!"这样的消息， 对你、对我们都没有好处．你的这个问题还会存在，而我们则对可能存在的 bug一无所知．如果你说"Whenever I select the foo item from the Foot menu, the entire panel disappears suddenly; by the way, what is this file that GNOME keeps putting in my home directory, it's called core." 就有用多了(当然还不够)。
理想地，我们需要从你那里得到一些信息．首先，你运行的到底是什么 样的系统?不，并不是每个人都和你用同样的操作系统．我们也需要知道 处理器类型: Sparc, MIPS, i386 (这包括 Pentiums, AMD, Cyrix, 等)， PPC, Alpha, ARM, 680x0, 或者其它;我们需要知道操作系统: Linux distribution, FreeBSD, HURD, OpenBSD, Solaris, IRIX, CrayOS, OS/400, 不管是什么．同时也包括操作系统的版本．比如我 正在用的机器是GNU/Linux RedHat/i386 Rawhide，我的一个朋友用 的是Solaris Sparc 2.6.
其次，我们需要有关你系统的一些重要统计信息．在GNU/Linux系统中， kernel和libc的版本号几乎总是有用的．在几乎所有GNOME的问题中， 我们都需要你的 glib, gtk+, Imlib, ORBit和gnome-libs 的版本． 如果你没有把握，尽量包含它们．除非你看到错误信息中提到，其它如 Perl, X11, Python, Guile 和libpng的版本信息，你可以不去管它． 另外一点重要的是你安装GNOME的方式．你用的是二进制包(哪一种)? 还是用tarball(压缩的tar包:译者)?你用CVS了吗?如果是，是什么时 候的和/或哪个标签(tag)的?如果你同时用了上面几种，请告诉我 们．
最后，我们需要问题本身。我们要确切地知道出现问题时你在干什么。 我们要知道这问题是经常性地还是偶然的。我们需要知道在问题发生前 程序是否输出了什么东西。我们需要知道当出现问题时确实发生了什么 事。如果你想要弄清楚，可以试着用一些我在下面将要提到的诊断工 具，比如backtrace，并把所得的信息包含在邮件中。
好了，在你准备发送前，你需要一个好的主题。Gnome-list里有大量的 信件，你当然希望那些能够帮助你的人看到你的消息，而帮不了你的人 则可以随意跳过。一个象"GNOME is broken"这样的主题很可能没人理睬； 而"GSM sucks"更可能激怒别人，显然于事无补；象"Most panel icons on HP-UX are just black squares" 这样才会被正确地注意。
把所有这些写进你的邮件，寄给Mailing-List．如果你照我的话做了， 很快就能收到仔细的答复．如果由于某种原因你没有及时收到，那它也许是 丢失了．等几天，看是否可以写得更详细点，描述得更清楚一点， 然后再寄一次．
如果你发现了bug，我们希望了解它，跟踪它，并且纠正它．为了使 这个过程更加有效，我们借用了Debian优秀的bug跟踪系统．在 http://bugs.gnome.org/Reporting.html有关于 如何使用它的完整帮助．
在向系统发送bug报告时要注意以下几点：首先查看 http://bugs.gnome.org以确保系统还未知道你的bug，如果它是新的， 就发送给submit@bugs.gnome.org； 确保你已经按照说明包含了包和版本标题，这使它能快速，自动地转给合适的 人；确保你包含了所有的详细信息，参见上一个问题关于哪些是有用的信息； 如果backtrace或strace是合适的，一定包含它，下面有关于如何做的说明．
一旦你向系统提交了bug报告，你将通过email得到反馈，同时也可以通过 bug跟踪系统的WEB前端跟踪bug的状态.
当GNOME编译时，你需要指定它在文件系统中的位置，它由选项 --prefix所指定，此选项被称为 GNOME Prefix(GNOME前缀)或简称prefix(前缀)．GNOME中文件 在不同系统中的位置除了前缀外应该是一致的．所以在某个系统 /usr/share/gnome/pixmaps中的文件， 在另一系统里可能在 /opt/gnome/share/gnome/pixmaps中，我们可以说它的位置是 $prefix/share/gnome/pixmaps．
如果你从tarballs(或CVS)安装，并且没有给configure (或autogen.sh)指定过前缀 ，则缺省是 /usr/local，如果你安装的是RedHat的 RPMS，它们用的前缀是/usr。如果你还 是不能确定，输入which panel，把结果 从尾部去掉 /bin/panel，剩下 的就是你的前缀。
大多数的Unix或Unix类系统都有一种叫做存储保护(memory protection) 的特点。这是指程序可以或被禁止存取某些内存区域（通常称为段）。 如果程序试图存取它被允许存取的段以外的内存，则系统就检测到问题， 并产生错误信号。这个错误就称为段故障（Segmentation Fault，在有些系统中 简称“segv”），通常程序会突然终止，留下一个core dump(见下）。
这意味着你的程序中存在bug，这bug可能是GNOME的源码中，也可能是在 你程序用到的共享库(shared libraries)中，或是与你编译的方式有关。 如果你不知道这bug是在GNOME还是在其它别的地方，可以问Mailing-list。 如果你确认这是GNOME中的bug，请确保它出现在bug跟踪系统中。
在电子计算机发展的初期，计算机内存是一束称为磁心(core)的磁性 环，这种内存就叫作磁心内存(core memory)．程序员如果想要知道程序 将如何运行，他们就输出磁心内存中内容的一份副本并加以分析，这个 输出就被称为core dump，虽然磁心内存早已过时，这个术语却 一直被保存下来了．
在很多Unix和Unix类系统中，当程序出现灾难性失败，比如段故障(Segmentation Fault，见上)时，系统会自动产生core dump，通常系统会把core dump放在 程序运行时所在目录中的称为core的文件中． 这个文件对于调试程序为何失败非常有用，同时也可以用来产生backtrace(见下)． 另一方面，这个文件可能非常大，特别是如果你不准备用它来调试时，显得太 大了，如果你不需要，查看你的系统文档以去掉这一功能．
一个非常有用的调试工具是backtrace，这实际上是程序当前运行处的 一个快照．它通常是在程序崩溃(意外退出，常伴有段故障或其它错误) 或者挂起(停止运行但不退出)时所做．这里假设你用的是GNU项目的 GDB调试器，因为这是用GNOME时常用并且也是我所用的，如果你用的是 其它的调试器，参照你的文档．
有两种方法做backtrace:你可以用程序崩溃时留下的core文件，也可以 直接在调试器里运行程序．我发现在调试器里运行程序更可靠，不过我 也会讲用core文件的方法．
要用GDB运行程序，可以在xterm(或类似的东西)里，输入 gdb <full name and location of program>， 比如，要调试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) |
用core dump作backtrace是十分类似的：到core dump所在的目录，然后 运行gdb -c core <full name and location of program>，再说一遍，GDB不搜索你的路径，你需要指定 在哪里能找到程序．然后你所要做的就是在提示下输入 bt，并且把整个会话送出去．
strace 命令用来运行一个程序，当它运行时输出系统调用和信号。这是一个比 backtrace更冗余的调试工具，不过有时你需要strace能给你的额外信息。 要得到一个strace很容易，只需在xterm中输入 strace -o <output file> <command with args> 。例如想关闭声音对gtalk程序作strace，我可以做 strace -o /tmp/gtalk.strace gtalk --disable-sound． 这将把strace的输出保存在 /tmp/gtalk.strace中。strace确实使用 路径，也确实接受命令行参数。
警告，strace产生大量的输出（上面的例子在5秒钟内产生多达5498行 的信息）。所以不要把strace发到Mailing Lists，除非当开发者要求时 发送给他们。