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 ~/.ekg2/core.<pid>
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.