2013-04-23 12 views
6

Pracuję nad aplikacją serwera C o wysokiej przepustowości działającą jako demon. W pewnych okolicznościach aplikacja ulega awarii (zawsze bez rdzenia). Jak mogę debugować demona uruchomionego za pomocą gdb, aby znaleźć miejsce, które generuje SIGSEGV?Debugowanie demona uruchomieniowego przy użyciu gdb

Objaśnienia:

  1. wiem jak podłączyć za pomocą gdb procesie uruchomionym poleceniem dołączyć

  2. Po dołączeniu do procesu, to zatrzyma. Jeśli uruchomię to "kontynuuj", gdb pozostanie zablokowane, jeśli program się nie zawiesza. Jeśli naciśniesz CTRL-C, proces się kończy i nie mogę po prostu odłączyć gdb.

Pytanie brzmi: czy istnieje sposób na kontynuowanie procesu bez utknięcia gdb, ale możliwość odłączenia się, jeśli proces się nie zawiesza?

+0

Czy próbowałeś zmienić ustawienia coredump np komenda 'ulimit'? I/lub uruchomić wersję debugowania? A może dodać więcej rejestrowania, aby zawęzić możliwe miejsca awarii? –

+0

Próbowałem wszystkich możliwości. Proces działa jako usługa typu "upstart" na serwerze Ubuntu i jest ustawiony na określonego użytkownika podczas uruchamiania usługi. Plik limits.limf zawiera nielimitowane wartości dla nofile i rdzenia dla tego użytkownika. Ustawiłem fs.suid_dumpable i kernel.core_uses_pid w /etc/sysctl.conf Dodałem więcej rejestrowania, ale jest to serwer o wysokim natężeniu ruchu i generuje zbyt dużo danych wyjściowych. –

Odpowiedz

3

Ta strona attach/detach mówi, że polecenie detach zadziała wewnątrz gdb.

Jeśli chcesz złapać błąd segmentacji w aplikacji, będziesz musiał uruchomić aplikację z debuggera. Następnie, gdy sygnał zostanie przechwycony, możesz użyć where lub bt, aby zobaczyć ślad stosu aplikacji. Oczywiście nie możesz kontynuować aplikacji po tym, jak ją zarzucono, jak powinieneś ją odzyskać? Jeśli spodziewasz się wkrótce spowodować błąd, możesz dołączyć się do uruchomionego procesu i ponownie poczekać na błąd w debugerze.

Jeśli chcesz śledzić stos po wystąpieniu błędu, naprawdę potrzebujesz pliku core, ponieważ nie będzie żadnego procesu, do którego można by dołączyć. Teraz, jeśli twój demon zostanie uruchomiony jako część systemu, może być trudno uzyskać konfigurację zrzutu jądra, a ponadto możesz nie chcieć, aby inne aplikacje opuszczały zrzuty rdzenia w każdym miejscu. Tak więc radziłbym zatrzymać demona systemu i uruchomić go ponownie w przestrzeni użytkownika, a następnie zezwolić na zrzucenie rdzenia. Jeśli naprawdę ważne jest, aby uruchamiał się jako część systemu, sprawdź, czy uruchomienie demona jest ograniczone do pojedynczej pod-powłoki i użyj ulimit -c w tej pod-powłoce, aby ustawić odpowiedni maksymalny rozmiar dla rdzenia wysypisko.

+0

Wiem, ale po uruchomieniu polecenia "kontynuuj", jedynym sposobem na wyjście z gdb jest naciśnięcie CTRL-C, co zatrzymuje trwający proces. –

+0

Użyj 'odłącz 'zamiast' kontynuuj', a następnie użyj 'quit'. Pracuje dla mnie. –

+0

Rozumiem, ale chcę móc uzyskać ślad, jeśli proces się zawiesza. –

6

asynchroniczny tryb Try i "kontynuować &":

Zapisz poniżej aby non-stop.gdb

set target-async on 
set pagination off 
set non-stop on 

Następnie uruchom:

$ gdb -x non-top.gdb 
(gdb) !pgrep YOUR-DAEMON 
1234 
(gdb) attach 1234 
(gdb) continue -a & 
(gdb) 
+0

Dziękuję. Spróbuję tego i opublikuję informację zwrotną. –