// szybki kurs obsługi gdb
// (c) copyright 2002 wojtek kaniewski <wojtekka@irc.pl>

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: gdb.txt,v 1.2 2002-11-12 16:39:28 wojtekka Exp $
