Z jakimi najtrudniejszymi bugami mieliście do czynienia w swoim doświadczeniu?
Mi się zdarzyło kiedyś użyć printfa w linuksowym signal handlerze, co skutkowało losowymi deadlockami. A że wtedy programowania na Linuksa praktycznie nie znałem tak więc spędziłem 2 dni na czytaniu dokumentacji i przeglądaniu kodów (np. printfa).
Klasa będąca singletonem wyglądająca mniej więcej tak:
klasa:
+ getInstance
+ setCallback(pointer)
+ setParam(pointer)
+ operacja
- callback
- param
Metoda operacja korzystała z domyślnego parametru dodatkowego i własnej funkcji zwrotnej do zwrócenia jakiś tam danych, jeśli użytkownik obiektu klasa sam nie ustawił swojego parametru i callbacka. Miałem kilka klas file, do których dałem metody takie jak save, etc. Metoda save odpalała oddzielny wątek, abym mógł równolegle zapisywać pliki zwrócone przez obiekt klasy klasa. W wątku file ustawiało dodatkowy parametr jako this, własny callback i wywoływało metodę operacja, która zwracała zawartość pliku do zapisania do callbacka. Nazwa pliku do którego dane miały trafiać była składową obiektu file. Błędu szukałem dobre kilka godzin :D
Dodam, żeby było jasne. Ten callback, który file ustawiał był metodą statyczną klasy file dlatego leciał this w parametrze, aby za jego pomocą można było nazwę pliku pobrać z obiektu file.
/*
Calculate the line segment PaPb that is the shortest route between
two lines P1P2 and P3P4. Calculate also the values of mua and mub where
Pa = P1 + mua (P2 - P1)
Pb = P3 + mub (P4 - P3)
Return FALSE if no solution exists.
*/
int dist3D_Return_Closest_Points_Between_Segments(
t3dpoint p1,t3dpoint p2,t3dpoint p3,t3dpoint p4,t3dpoint &pa,t3dpoint &pb)
{
t3dpoint p13,p43,p21;
double d1343,d4321,d1321,d4343,d2121;
double numer,denom;
double mua; double mub;
p13.x = p1.x - p3.x;
p13.y = p1.y - p3.y;
p13.z = p1.z - p3.z;
p43.x = p4.x - p3.x;
p43.y = p4.y - p3.y;
p43.z = p4.z - p3.z;
if (Abs(p43.x) < SPECIAL_FEAUTRE && Abs(p43.y) < SPECIAL_FEAUTRE && Abs(p43.z) < SPECIAL_FEAUTRE)
return(FALSE);
p21.x = p2.x - p1.x;
p21.y = p2.y - p1.y;
p21.z = p2.z - p1.z;
if (Abs(p21.x) < SPECIAL_FEAUTRE && Abs(p21.y) < SPECIAL_FEAUTRE && Abs(p21.z) < SPECIAL_FEAUTRE)
return(FALSE);
d1343 = p13.x * p43.x + p13.y * p43.y + p13.z * p43.z;
d4321 = p43.x * p21.x + p43.y * p21.y + p43.z * p21.z;
d1321 = p13.x * p21.x + p13.y * p21.y + p13.z * p21.z;
d4343 = p43.x * p43.x + p43.y * p43.y + p43.z * p43.z;
d2121 = p21.x * p21.x + p21.y * p21.y + p21.z * p21.z;
denom = d2121 * d4343 - d4321 * d4321;
if (Abs(denom) < SPECIAL_FEAUTRE)
return(FALSE);
numer = d1343 * d4321 - d1321 * d4343;
mua = numer / denom;
mub = (d1343 + d4321 * mua) / d4343;
pa.x = p1.x + mua * p21.x;
pa.y = p1.y + mua * p21.y;
pa.z = p1.z + mua * p21.z;
pb.x = p3.x + mub * p43.x;
pb.y = p3.y + mub * p43.y;
pb.z = p3.z + mub * p43.z;
return(TRUE);
}
do dzisiaj nieobilcza porpawnie wszystkiego
problemy z watkami przy cross testowaniu projektu
Deadlock na bazie danych (MS SQL Server 2005). Błędy wynikały z implementacji biblioteki w c++, która w transakcji wykonywała dużo obliczeń kilka razy pobierając i aktualizując dane w bazie. Pojedyńcza transakcja trwała nawet 20 sekund. Zdiagnozowanie że to ta część aplikacji powoduje błąd zajęło prawie 2 dni (profiler jest nieoceniony). Odtworzenie sytuacji na środowisku testowym też nie było łatwe. A na koniec okazało się że tej biblioteki w c++ nie można ruszyć, więc stanęło na workaround (grrrr).
A tak na marginesie, większość błędów która wydaje się komuś trudna wynika z lukach w wiedzy dotyczących danego zagadnienia. Mówię to z autopsji.
Ale obiektywnie trudne błedy to te, o których za mało mamy informacji, aby dojść do tego gdzie leży problem lub są ciężkie w do odtworzenia na środowisku testowym/developerskim. Trudnością jest tu zlokalizowanie problemu, a nie sama algorytmika.
Ach, mam jeszcze jedną perełkę. Znowu biblioteka w c++, komunikacja przez rpc i problem z stale rosnącą pamięcią procesu serwera (który działał jako usługa windows) i rosnącą liczbą tzw. uchwytów. Projekt był baaardzo rozbudowany, składał się z kilkudziesięciu bibliotek c/c++, część autorskich, część open source. Debugowanie tego było wyjątkowo trudne, a miejscami właściwie niemożliwe. Do problemu podchodziło kilka osób, kilka razy, na przestrzeni miesiąca. W końcu udało mi się namierzyć że bibloteka odpowiedzialna za komunikację gdzie tworzony był socket ma bug'a. Zdaje się że była to część kliencka, po nieudanym connect nie było prawidłowego zwolnienia socketa, tylko return. Poprawka błędu to banał. Ale jego odnalezienie to droga przez mękę.
Obsługa sprzętowego FIFO UARTu w pic24FJ64GB106. Chodziło o obsługę flag błędów. Po jakimś czasie Microchip wydał Erratę w której opisali błędy w sprzęcie z dopiskiem "Work around: None". 2 dni w plecy.
SELECT ...
UNION
SELECT ...
zamiast UNION ALL. Niejawnie wykonywało się distinct, ...a klient zdziwiony, my też, bo kto by się spodziewał błędu w prostym zapytaniu, ale mały szczególik umknął...
brak volatile powodował, że program się wieszał. ale tylko na releasie, na debugu działało. i trzeba było kombinować, czemu nie działa
Kod jeszcze ze szkoły:
if (warunek);
operacja();
Niby banał, a trochę czasu mi zajęło znalezienie tego błędu.
Najgorsze bugi są wtedy, gdy raz działa a raz nie.
Czarna księga bugów a.k.a. horror dla każdego programisty:
http://en.wikipedia.org/wiki/Unusual_software_bug
Nie zdarzył mi się jeszcze żaden, może oprócz Bohrbuga raz czy dwa. I mam nadzieję że to się nie zmieni... brr.
Ja znam buga (nie w własnym kodzie). Mianowicie jak ktoś wyjmie kartę płatniczą z czytnika za wcześnie to karta staje się bezużyteczna gdyż transakcja wisi sobie w powietrzu...
Aplikacja webowa, zarządzanie rolami przez AzMana. Po zainstalowaniu i poprawnym skonfigurowaniu oraz oczywiście odpaleniu tego skryptu: http://blogs.msdn.com/b/azman/archive/2007/03/23/bizrules-opt-in.aspx autoryzacja nadal nie działała. Szukanie błędu zajęło ponad tydzień, rozwiązaniem było uruchomienie tego skryptu z 32bitowej wersji cmd. :D