// szybki kurs obsługi gdb // (c) copyright 2002 wojtek kaniewski jeśli program się wywrócił i utworzył plik core, za pomocą gdb można sprawdzić, w którym miejscu wystąpił błąd. najpierw uruchamiamy gdb: $ gdb ekg ~/.gg/core GNU gdb 5.0 (UI_OUT) Copyright 2000 Free Software Foundation, Inc. (...) #0 command_test_segv (name=0x80617c9 "_segv", params=0x8088c20) at commands.c:1601 1601 return (*foo = 'A'); (gdb) od razu widzimy, że błąd wystąpił w funkcji ,,command_test_segv'' z pliku commands.c. potem widzimy błędną linię. w niektórych przypadkach niestety to nie wystarcza. możliwe, że linia, w której wystąpił błąd jest poprawna, ale dostarczone dane nie były właściwe. wtedy z pomocą przychodzi polecenie ,,bt'', które wyświetla stos wywołań funkcji. widzimy dzięki temu po kolei, jaka funkcja wywoływała jaką funkcję i z jakimi parametrami: (gdb) bt #0 command_test_segv (name=0x80617c9 "_segv", params=0x8088c20) at commands.c:1601 #1 0x080506e2 in old_execute (target=0x0, line=0x0) at commands.c:2009 #2 0x08050980 in ekg_execute (target=0x0, line=0x806d700 "_segv") at commands.c:2136 #3 0x08059192 in ui_ncurses_loop () at ui-ncurses.c:231 #4 0x080578d8 in main (argc=1, argv=0xbffffb24) at ekg.c:726 #5 0x4008e38f in __libc_start_main () from /lib/libc.so.6 teraz widzimy, że po prostu użytkownik wywołał komendę ,,_segv''. co prawda widać to po samej nazwie funkcji, w której wystąpił błąd, ale w większości przypadków nie będzie to aż tak oczywiste. niestety zdarza się i tak, że błędny kod narusza ważne obszary pamięci, a sam błąd występuje później, chociażby przy wywoływaniu funkcji alokacji pamięci. w takich przypadkach zlokalizowanie błędu jest znacznie trudniejsze. $Id$