Akkor is, ha betűre pontosan követed a fenti leírást, előfordulhatnak előre nem látható problémák. Bármivel lehet gond, a félreolvasott utasításoktól kezdve, a szoftver hibáján át, a más szoftverében található hibákig bármi elképzelhető. Ebben a fejezetben megpróbáljuk leírni, hogy mások milyen problémákkal találkoztak a GNOME telepítése vagy használata során.
Itt néhány általános, gyakran felmerülő kérdést tárgyalunk, a specifikus problémákat lásd később, ebben a fejezetben.
OK, az első tanácsom, lazíts egy kicsit és végy egy nagy levegőt... Ezek után olvasd át ezt a GyIK-et, a GNOME Felhasználói Kézikönyvet és bármilyen más a kezed ügyébe kerülő doksit, keresvén a megoldást. A következő lépésben olvasd át a levelezőlista archívumát (erről olvashatsz feljebb) abból kiderül, hogy van-e más, akinek ugyanaz a problémája. Nagyon fontos: próbáld meg még egyszer azt, ami úgy tűnik, hogy nem sikerül, hátha a megoldás adja magát. Ha semmi sem segít, elérkezett az idő, hogy kérdezz a listán.
Először is, fel vagy iratkozva a gnome-list listára, igaz? Ha nem vagy, a feliratkozáshoz szükséges tudnivalókat megtalálod feljebb. Na most, amikor segítséget kérsz a listán, részletesen írd le a problémád. Ha csak annyit mondasz, hogy "A panel nem műxik" ez sem rajtad, sem rajtunk nem segít. Neked még mindig ott lesz a problémád, nekünk meg egy lehetséges programhibánk, amiről semmit sem tudunk. Hasznosabb (de még mindig nem elég), ha valami ilyet írsz: "Mindig, amikor kiválasztom az "akármilyen" menüpontot a Tappancs menüből, az egész panel hirtelen eltűnik. Ja, ha már itt tartunk, mi az a core nevű fájl amit a GNOME állandóan a "home" könyvtáramba rak?"
Ideális esetben többféle információra van szükségünk. Először, pontosan milyen rendszered van? Nem, nem mindenki ugyanazt az operációs rendszert használja. Meg kell adnod a processzor típusát: Sparc, MIPS, i386 (ebbe beletartozik a Pentium, az AMD, a Cyrix stb...), PPC, Alpha, ARM, 680x0... Tudnunk kell az operációs rendszeredet pontosan: Linux disztribúció, FreeBSD, HURD, OpenBSD, Solaris, IRIX, CrayOS, OS/400, meg ilyenek. Add meg ezen kívül az operációs rendszer pontos verzióját. Például, az a gép, ami előtt most ülök egy GNU/Linux RedHat/i386 Rawhide gép, az egyik barátom pedig egy Solaris Sparc 2.6-os gépet használ.
Ezek után szükségünk van egyéb információkra is, azzal kapcsolatban, hogy mit használsz a gépen. A GNU/Linux rendszereken a kernel száma és a libc verziója szinte biztos, hogy kell. Majdnem minden GNOME problémához szükségünk van a glib, gtk+, Imlib, ORBit és gnome-libs verzióira. Ha nem vagy biztos benne, hogy szükségünk van ezekre az adatokra, inkább írd csak le őket. Más dolgok, amik néha összefüggésben lehetnek a problémáddal, a Perl, X11, Python, Guile és libpng verziói, ám ha nem látsz az egyikükre utaló hibaüzenetet, nem kell megadnod őket. Szintén fontos, hogy hogyan telepítetted a GNOME-ot. Binárisokat használtál? Ha igen, melyik verziót? CVS-ből telepítetted a GNOME-ot? Ha igen milyen dátummal? Ha a fenti módszereket kombináltad, írd le azt is.
Végül, tudnunk kell pontosan, hogy mi a problémád. Tudnunk kell, hogy a probléma mindig jelentkezik, vagy csak néha. Tudnunk kell, hogy a program ad-e valamilyen hibaüzenetet mielőtt elszáll. Tudnunk kell, hogy pontosan mi történik, amikor találkozol a hibával. Ha ambiciózus vagy, próbálkozhatsz valamelyik diagnosztizáló eszközzel, amelyekről mindjárt írok, csinálhatsz pl. egy "backtrace"-t, ezt az információt is beleveheted a levélbe.
Most, hogy készen állsz arra, hogy feladd a levelet, kell egy jó, frappáns tárgy (subject). A GNOME-list-nek nagy forgalma lehet, azt akarod tehát, hogy a Te leveledre felfigyeljenek azok az emberek, akik segíteni tudnak, akik nem, azok pedig rögtön át tudják ugrani. Ha tehát azt írod a subject mezőbe, hogy "A GNOME nem működik", mindenki át fogja ugrani a leveledet, ha azt írod, hogy "GSM suxx", csak dühíteni fogod azokat, akiktől a segítséget várnád; ha valami olyasmit írsz, hogy "HP-UX alatt, a GNOME-panel ikonjai helyett csak fekete négyzetek jelennek meg", valószínűleg a megfelelő emberek érdeklődését kelted fel.
Szóval minden fent említett részletet összegezz egy hosszú e-mail-ben, és küldd el azt a listára. Ha követted a tanácsaimat, jó esélyed van arra, hogy gyorsan és átgondoltan válaszolni fognak. Ha valamilyen okból mégsem jön válasz, ne vedd személyes sértésnek, a leveled valószínűleg elkallódott a hatalmas levéltömegben. Várj néhány napot, majd gondold át, hogy tudsz-e még valami hasznos információt hozzátenni, vagy egy többet mondó fejlécet, és küldd el a levelet újra.
Ha találsz egy hibát (bug), mi tudni akarunk róla, meg akarjuk keresni és ki akarjuk javítani. Hogy minél hatékonyabbá tegyük ezt a folyamatot, kölcsön vettük a Debian kiváló hibakövető rendszerét. A rendszer használatáról olvashatsz a következő oldalon: http://bugs.gnome.org/Reporting.html.
Néhány dologra oda kell figyelni a hibakövető rendszer használatakor. Először nézd át a webes felületet a http://bugs.gnome.org-on, itt láthatod, hogy a hibát más bejelentette-e. Ha új hibáról van szó, küld el a submit@bugs.gnome.org címre. Vigyázz arra, hogy megadd a Csomag és Verzió fejléceket, ahogyan az a használati utasításban le van írva, ezzel biztosítod, hogy a hibabejelentés gyorsan és automatikusan a megfelelő emberekhez kerül. Nézd át, hogy minden részletet megadtál-e. Lásd az előző kérdésnél leírtakat. Ha a backtrace vagy az strace kimenete releváns, mindenképpen csatold. Arról, hogy mik ezek, lejjebb olvashatsz.
Miután bejelentetted a rendszeren keresztül a hibát, kapsz egy levelet róla. A hibakövető rendszer webes felületén figyelemmel kísérheted a hiba státuszát.
Amikor a GNOME-ot lefordítják, meg kell adni azt a helyet, ahol a GNOME fájljai találhatók a fájlrendszerben. Az opció, amivel ezt állíthatod, a --prefix, ezért ezt a helyet GNOME Prefix-nek, vagy röviden prefix-nek vagy előtagnak hívjuk. A GNOME fájljainak az elhelyezkedése megegyezik rendszerről rendszerre, a prefix kivételével, tehát lehet, hogy egy fájl a /usr/share/gnome/pixmaps könyvtárban az egyik gépen a /opt/gnome/share/gnome/pixmaps könyvtárban van a másikon, ezért erre a helyre úgy hivatkozunk, hogy: $prefix/share/gnome/pixmaps.
Ha tar csomagból (vagy CVS-ből) telepítetted a GNOME-ot, de nem adtad ki a configure (vagy az autogen.sh) parancsokat a megfelelő prefix-szel, az alapértelmezett hely a /usr/local. Ha RedHat RPM-ekből telepítetted a GNOME-ot, akkor a prefix beállítása a /usr. Ha még mindig nem vagy biztos, írd be, hogy which panel, és vond ki az eredményből a /bin/panel-t. Ami maradt, az a GNOME prefix.
A legtöbb UNIX és UNIX jellegű rendszernek van egy memóriavédő mechanizmusa. Ez azt jelenti, hogy a program elérhet bizonyos memória területeket (ezeket gyakran memóriaszegmenseknek hívjuk), másokat viszont nem. Ha a program a megengedett memóriaszegmensen kívül próbál a memóriához hozzáférni, az operációs rendszer ezt észleli, és hibát jelez. Ezt a hibát hívják "Segmentation Fault"-nak, azaz szegmentációs hibának, vagy röviden "segv"-nek, egyes rendszereken. Ez általában úgy néz ki, hogy a program hirtelen befejeződik, gyakran "core dump"-ot hagy maga után (lásd lejjebb).
Leegyszerűsítve, ez azt jelenti, hogy a GNOME forrásában, vagy a program által használt osztott programkönyvtárban hiba van, de az is lehet, hogy a GNOME fordításakor sikerült valami rosszul. Ha nem vagy benne biztos, hogy a hiba a GNOME-ban van, kérdezd meg a listán. Ha a hiba a GNOME-ban van, jelentsd be azt a hibakövető rendszeren keresztül.
Az elektronikus számítógépek gyermekkorában, a memória néhány drótra felfüggesztett mágneses gyűrűből állt. Ezt a fajta memóriát hívták "core memory"-nak. Amikor egy programozó látni akarta, hogy mit csinál pontosan a programja, készített egy másolatot a memória tartalmáról, hogy később elemezze azt. Ezt hívták "core dump"-nak és a kifejezés megmaradt, jóval a "core" memóriák elavulása után.
Sok Unix és Unix-jellegű rendszer automatikusan létrehoz egy "core dump"-ot, ha egy program erőszakos halált hal :), pl. a fent említett szegmetációs hiba miatt. Általában ezt a core nevű fájlban találjuk, abban a könyvtárban, ahonnan a programot indítottuk. Ez a fájl nagyon hasznos, ha meg akarjuk állapítani, hogy miért szállt el a program, ezt lehet felhasználni backtrace készítéséhez (lásd lejjebb). Meg kell jegyeznünk, hogy a core fájl elég nagy lehet, ha nem használod fel hibakeresésre, akkor főleg feleslegesen foglalja a helyet. Ha nincs elég helyed, vagy nem látod értelmét annak, hogy core dump-okkal teljen meg a merevlemezed, nézz utána az operációs rendszered dokumentációjában, hogy hogyan tudod kikapcsolni ezt a "feature"-t.
A backtrace hihetetlenül hasznos, ha hibakeresésről van szó. Lényegében egy pillanatfelvételről van szó, ami azt mutatja, hogy hol tart a program a futásban. Backtrace-t (visszakövetést) akkor alkalmazunk, ha egy program elszáll (szegmentációs vagy más hiba miatt) vagy megfagy (megáll, nem működik, de nem száll el). Ebben a válaszban, abból indulok ki, hogy a GNU projekt GDB debugger-ét (hibakereső programját) használod, mert ez a legelterjedtebb program amit a GNOME hibáinak keresésekor használnak, és ezt a programot használom én is. Ha valamilyen más debugger-t használsz, olvasd el a megfelelő dokumentációt.
Két módszerrel lehet backtrace-t csinálni. Használhatod a core fájlt, amit a program generált amikor hibásan lépett ki, vagy futtathatod a programot a debugger-ből. Személyes véleményem, hogy a program debuggerben való futtatása megbízhatóbb eredménnyel szolgál, de szó lesz a core fájlos megoldásról is.
Ahhoz, hogy egy programot GDB-ben futtass, nyiss egy xterm-et (vagy valamilyen más terminált) és írd be, hogy gdb <a program teljes elérési útvonala és neve>, tehát, ha a gtalk-ban keresel hibát, beírhatod a következőt: gdb /usr/local/bin/gtalk. A GDB nem nézi végig a PATH változóban megadott útvonalakat, ezért kell megadnod a program helyét. Ha argumentumokkal vagy kapcsolókkal akarod futtatni a programot, ne írd be őket ide. A parancssorban megadandó argumentumokat később kell megadni.
Ekkor megjelenik a GDB, "bemutatkozik", majd kapsz egy (gdb) promptot. Ide kell annyit beírnod, hogy run és elindul a program. Ha argumentumokkal, vagy kapcsolókkal szeretnéd futtatni a programot, ide kell ezeket beírni. Pl.: run --disable-sound. Ekkor elindul a program. Meg kell jegyeznünk, hogy a program lassabban fog futni, és sokkal több memóriát fog használni, mint általában.
Most próbáld meg újra előidézni azokat a körülményeket, amelyek között a program elszáll. Csináld megint ugyanazt, ami már korábban is a problémát okozta. Amikor a program elszáll, a debugger ablakában azonnal meg kell jelenjen egy csomó minden, majd a (gdb) prompt. Ha a program megfagy, várj egy kicsit, győződj meg arról, hogy tényleg nem reagál, majd nyomjál egy "Control-C"-t a debugger ablakában. Ekkor is egy csomó dolog kell megjelenjen, végül a (gdb) prompt. Ennél a promptnál írd be, hogy: bt. Ez lesz a tényleges backtrace.
Itt van egy példa, a hibakereső kimenetére. Ha valaki backtrace-t kér tőled, az egészet be kell küldened:
$ 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) |
A backtrace készítése core dump alapján nagyon hasonlít az előbb tárgyaltakhoz. Lépj be abba a könyvtárba, amelyik a core fájlt tartalmazza, és futtasd a GDB-t a következőképpen: gdb -c core <a program teljes elérési útvonala és neve>. Ismételten felhívom a figyelmedet arra, hogy a GDB nem keresi a programot a PATH változóban megadott helyeken. Ezek után csak be kell írnod a promptnál, hogy bt és az egészet (mindent amit a gdb a program indítása óta kiírt) elküldened.
A strace parancs "Signal Trace"-t, azaz "Jelzés követést" valósít meg. Használatával, úgy futtathatod a programot, hogy közben látod a rendszer hívásokat és jelzéseket. Ez sokkal bőbeszédűbb mint a backtrace, néha szükség van az strace-re is. Strace-elni nagyon egyszerű, írd be egy xterm-be, hogy strace -o <kimeneti fájl> <parancs argumentumokkal>. Például, ha a gtalk programot szeretnéd strace-elni, úgy, hogy a hang ki legyen kapcsolva, a következőt kell megadni: strace -o /tmp/gtalk.strace gtalk --disable-sound. Ez a strace kimenetét a /tmp/gtalk.strace fájlba menti. Az strace használja a PATH változót és elfogadja a program-argumentumokat a parancssorban.
Vigyázz, az strace kimenete nagyon bőbeszédű, a fenti példa nálam 5498 sort produkált öt másodperc alatt. Ne küldj strace kimenetet a levelezőlistára, csak a fejlesztőknek, ha ők ezt kimondottan kérik.
A Solaris rendszereken van ugyan strace parancs, de az valami egészen mást csinál. Solaris alatt használd a truss parancsot, ha strace kimenetet szeretnél kapni.