W mojej aplikacji obsługuję SIGSEG, aby utworzyć ślad i wywołać abort() w celu wygenerowania zrzutu pamięci.Jak znaleźć wątek, który spowodował SEGFAULT w sesyjnej sesji gdb?
Jeśli teraz przeprowadzam analizę pośmiertną rdzenia gdb, wątek, który spowodował SEGFAULT, nie jest już widoczny. Czy jest coś, co mogę zrobić, więc widzę przyczynę SEGFAULT?
poważaniem, Martin
Można użyć polecenia thread apply all bt lub thread apply all bt full dostać śledzenia wstecznego wszystkich wątkach. Może być przydatne.
Przy okazji, jeśli pozbędziesz się obsługi, system operacyjny utworzy plik podstawowy?
Obecnie używam programu obsługi do zapisania śledzenia wstecznego na stderr, więc mam wszystko, ponieważ nie mogłem uzyskać niczego z pliku core. Muszę spróbować, jeśli domyślny program obsługi wygeneruje "lepsze" zrzuty pamięci. –
'ulimit -c unlimited' i zobacz jaki rdzeń otrzymasz bez żadnego programu obsługi. –
@skwllsp, czy jest jakiś sposób, aby dowiedzieć się, który wątek spowodował SIGSEGV? Czy miałeś na myśli to, że właściwie nie można tego wiedzieć, a ślady kręgosłupa muszą być użyte, aby je znaleźć? – russoue
Czy wykonujesz również inną pracę w programie obsługi? Dlaczego po prostu niech system operacyjny nie użyje domyślnego zachowania, aby zostawić dla ciebie rdzeń? –
Po prostu tworzenie zaległości na stderr, a następnie wywołanie abort(). –
Proszę podać swój system operacyjny i to, co dokładnie obserwujesz w GDB. Na Linuxie (i każdym innym Uniksie, jaki mogę sobie wyobrazić) obsługa SIGSEGV będzie działała w wątku, który spowodował SIGSEGV w pierwszej kolejności. Jeśli ten hander wywoła abort(), wówczas zrzut rdzenia będzie zawierał ten wątek jako wątek # 1 i nie będzie problemu ze znalezieniem dokładnie instrukcji i tego, jaki stos wywołań spowodował problem. Ponieważ masz problemy, jesteś albo na jakimś "dziwnym" systemie operacyjnym, albo nie opisujesz właściwie tego, co faktycznie obserwujesz. –