2016-06-06 24 views
6

Używam web.py do utworzenia serwera WWW Python. Ten serwer jest wywoływany w celu rozwiązania problemów programowania liniowego i używa biblioteki CBC, aby to zrobić.Serwer w języku Python "Aborted (Core dumped)"

Raz na jakiś czas, awarie serwerów z dziennika, który wygląda tak:

78.243.184.3:56271 - - [03/Jun/2016 04:35:54] "HTTP/1.1 GET /optimization" - 200 OK 
Aborted (core dumped) 

wierzę „przerwana (core dumped)” to błąd C, więc przychodzi albo web.py lub CBC.

Czy istnieje sposób, aby prześledzić źródło błędu?

+1

Może uda Ci się zlokalizować plik core. –

+0

Czy wiesz, jak to zrobić? – Arnaud

+0

Zależy od systemu. Może być 'find/-name" core "-ls" działa. –

Odpowiedz

4

Zrzut podstawowy jest spowodowany przez błąd w natywnym kodzie na serwerze internetowym. Python jest obecnie bardzo solidny, więc takie błędy są prawie zawsze spowodowane przez błędy w rozszerzeniach C na moim doświadczeniu.

Masz zatem 3 problemy.

  1. Musisz znaleźć plik zrzutu pamięci głównej. Zwykle znajduje się w bieżącym katalogu roboczym procesu, który został zrzucony. Istnieje jednak configation options that can change this.

  2. Musisz debugować stos wywołań, który się nie powiódł. Jest to objęte StackOverflow - zobacz How to analyze a program's core dump file with gdb?

  3. Być może będziesz musiał powiązać stos interpretera Pythona z powrotem z uruchomionym kodem Pythona. Aby to zrobić, musisz zainstalować symbole debugowania Pythona i rozszerzenia Python dla gdb. W wiki Pythona można znaleźć porady na temat tego, jak to zrobić: here.

+0

Dzięki za tę odpowiedź, sprawdzę gdb jutro. Mam kilka pytań: 1. Skąd wiadomo, że problem pochodzi z serwera WWW, a nie z CBC? 2. Czy zdajesz sobie sprawę, że problem pochodzi z biblioteki web.py, a nie z mojego kodu? 3. Nie znajduję żadnego pliku zrzutu pamięci głównej w katalogu server.py. Gdzie mogę znaleźć opcje konfiguracyjne web.py? 4. Jak usunąć błąd, jeśli jest w kodzie web.py? 5. Czy uważasz, że najlepszą opcją byłoby zmienić web.py na inną bibliotekę? Dzięki za pomoc! – Arnaud

+1

Generalnie nie mogę ci podać odpowiedzi. Masz zrzut rdzenia i uruchomiony gdb, który powie ci, gdzie jest błąd. Właśnie dlatego istnieją pliki podstawowe - do analizy post mortem. Aby uzyskać pomoc od kogokolwiek, musisz wyodrębnić stos wywołań za pomocą technik, które opisałem i zaktualizować twoje pytanie. –

+0

Ale błąd pojawia się juste co jakiś czas (raz na 2 lub 3 tygodnie), i nie jestem w stanie go odtworzyć ... – Arnaud

0

Najczęstszym powodem zrzutu pamięci jest uzyskanie dostępu do adresu pamięci poza Twoim zasięgiem (pamięć, która nie należy do twojego programu). System operacyjny przerywa działanie programu z przerwą o nazwie SegFault lub BusError, odrzucając sposób, w jaki program próbował uzyskać dostęp do nieprawidłowego adresu pamięci. Program zostanie następnie zdecydowanie zamknięty przez jądro. Jeśli jądro zostało skonfigurowane do tworzenia zrzutu pamięci (zrzut pamięci i stos programu), zostanie on zapisany na dysku. Jak wspomniano w drugiej odpowiedzi, możesz załadować zrzut rdzenia do GDB lub innego debuggera i wyświetlić, co program robił w momencie awarii. To może, ale nie musi, dać ci problem. Zwykle ciężko jest nawet doświadczonemu programiście używać tych narzędzi, więc bądź świadomy. Jeśli chcesz spróbować użyć GDB, spróbuj tego:

$ gdb/ścieżka/do/awarii/Program/binary/ścieżka/do/rdzeń

(gdb) bt

'bt' będzie wyświetla "ślady" śledzenia, znane również jako StackTraces, i może być przydatne dla programisty w celu wyśledzenia błędu.

Jeśli jesteś w stanie odtworzyć błąd, prawdopodobnie masz szczęście, przesyłając szczegółowe zgłoszenie błędu do twórcy danego programu. Nawet ja, jako starszy programista, od czasu do czasu podróżuję tą trasą. :-)