Debugowanie plików podstawowych generowanych w skrzynce klienta

Dostajemy podstawowe pliki z naszego oprogramowania w skrzynce klienta. Niestety, ponieważ zawsze kompilowaliśmy z -O2bez debugowanie symboli doprowadziło do sytuacji, w których nie mogliśmy dowiedzieć się, dlaczego nastąpiło awarie, zmodyfikowaliśmy kompilacje, więc teraz generują razem -g i -O2. Następnie radzimy klientowi, aby uruchomił -g plik binarny, aby ułatwić debugowanie.

Mam parę pytań:

Co się dzieje, gdy plik rdzenia jest generowany z dystrybucji Linuksa innej niż ta, którą uruchomiliśmy w Dev? Czy ślad stosu jest nawet znaczący?Czy są jakieś dobre książki do debugowania w systemie Linux lub Solaris? Coś zorientowanego na przykład byłoby wspaniałe. Poszukuję przykładów z życia codziennego, aby dowiedzieć się, dlaczego rutyna uległa awarii i jak autor doszedł do rozwiązania. Coś więcej na poziomie pośrednim do zaawansowanego byłoby dobre, ponieważ robię to już od jakiegoś czasu. Pewne zgromadzenie byłoby również dobre.

Oto przykład awarii, która wymaga, abyśmy powiedzieli klientowi, aby otrzymał -g ver. binarny:

Program terminated with signal 11, Segmentation fault.
#0  0xffffe410 in __kernel_vsyscall ()
(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x00454ff1 in select () from /lib/libc.so.6
...
<omitted frames>

Idealnie chciałbym rozwiązać problem, dlaczego właśnie ta aplikacja uległa awarii - podejrzewam, że to uszkodzenie pamięci, ale nie jestem w 100% pewien.

Zdalne debugowanie jest surowo zabronione.

Dzięki

questionAnswers(4)

yourAnswerToTheQuestion