Pierwszą rzeczą, aby szukać jest komunikat o błędzie, który pojawi się, gdy awarii programu. Dzięki temu często dowiesz się, jaki błąd wystąpił. Na przykład: "Błąd segmentacji" lub "SIGSEGV" prawie na pewno oznacza, że Twój program usunął odnośnik NULL lub w inny sposób nieważny. Jeśli program jest napisany w C++, to komunikat o błędzie często wskaże nazwę nieprzechwyconego wyjątku.
Jeśli nie widzisz komunikatu o błędzie, uruchom program z wiersza poleceń lub potnij jego wyniki w pliku.
Aby plik podstawowy był naprawdę przydatny, należy skompilować program bez optymalizacji i informacji o debugowaniu. GCC wymaga następujących opcji: -g -O0. (Upewnij się, że twoja kompilacja nie ma żadnych innych opcji -O.)
Gdy masz plik core, a następnie otworzyć go w gdb z:
gdb YOUR-APP COREFILE
Rodzaj where zobaczyć miejsce, w którym wystąpiła awaria. Zasadniczo jesteś w normalnej sesji debugowania - możesz badać zmienne, poruszać się w górę iw dół stosu, przełączać się między wątkami i czymkolwiek.
Jeśli twój program się zawiesił, prawdopodobnie jest to nieprawidłowy dostęp do pamięci - musisz więc szukać wskaźnika o zerowej wartości lub wskazać źle wyglądające dane. Możesz nie znaleźć problemu na samym dole stosu, zanim znajdziesz problem, możesz przesuwać go o kilka poziomów w górę.
Powodzenia!
Dziękujemy za szczegółową odpowiedź. Serwer został skompilowany z informacjami o debugowaniu i tworzy zrzut główny, gdy się zawiesza. Serwer inicjuje wiele wątków. Za każdym razem, gdy wątki są mniejsze niż 200, serwer działa dla bitów dłużej niż godzinę, ale gdy wzrost liczby żądań zwiększa liczbę wątków w puli do około 300, serwer ulega awarii znacznie wcześniej. Czy możesz mi powiedzieć, w jaki sposób może pomóc użycie debugującej wersji malloc? Dzięki –
Jeśli chodzi o "debugowanie malloc": jeśli problemem jest nadużywanie pamięci, to malloc debugowania pomoże, nagrywając więcej informacji o przydzielonej przestrzeni, zwykle poprzez przydzielenie większej ilości miejsca, więc gdy jego funkcje są wywoływane, mogą wykryć różne rodzaje nadużywania pamięci na początku procesu - ograniczanie zadawanych obrażeń i zwykle ułatwiło dostrzeżenie problemu. Na przykład, jeśli uwolnisz już uwolnioną porcję pamięci, może to zgłosić - zamiast po prostu wziąć swoją wartość za darmo i pracować z informacjami, których tak naprawdę tam nie ma. Zobacz K & R dla prostej implementacji malloc(). –
Odnośnie "poniżej 200 wątków OK; ponad 300 wypadków wcześniej "; czy sprawdziłeś, czy serwer przydziela pulę o stałym rozmiarze jakiegoś zasobu (może 200, może 256) i czy nie sprawdza poprawnie wyczerpania tego zasobu. Może to być zestaw muteksów lub semaforów lub coś innego, co powoduje nadużywanie pamięci. Czy kod serwera został napisany? Czy warto rozważyć ograniczenie liczby wątków w pracy? –