Отклањање грешака

Дебаговање је процес проналажења и решавања багова или недостатака који спречавају предвиђену радњу рачунарског софтвера или система. Дебаговање има тенденцију да буде теже када су различити подсистеми чврсто повезани, пошто промене у једном могу да проузрокују настанак багова у другом. 

Бројне књиге су написане о дебаговању (видети испод: Додатна литература), пошто укључује броје аспекте, укључујући интерактивно дебаговање, контролу протока, интеграционо тестирање, лог фајлове, мониторинг (апликација, систем), депонија меморије, профилисање, статистичко управљање процесом, и специјална тактива дизајна да унапреди детекцију док поједноставља промене.

Порекло

Евиденција ставке компјутера из Марк II, са мољцем залепљеним на страну.

Термин "баг" и "дебаговање" су популарно приписани адмиралу Грејс Хопер 1940-те. Док је она радила на рачунару Марк II на универзитету Харвард, њени сарадници су открили мољца заглављеног у релеју и на тај начин је ометао рад, након чега је она поменула да она "дебагује" систем. Међутим термин "баг" у значењу техничке грешке датира још из 1878. и потиче од Томаса Едисона (погледати софтверски баг за целу дискусију), и "дебаговање" делују да су коришћени као термин у ваздухопловству пре улазка у свет рачунара. Мољац се уклапао у већ постојећу терминологију, тако да је сачуван. Писмо Роберта Опенхајмера (директора пројекта Менхетн из Другог светског рата у Лос Аламосу са циљем израде атомске бомбе) је користио термин у писму за Ернеста Лоренца са Универзитета Калифорније (Беркли), датирано на 27. октобар 1944, у бези са запошљавањем додатног техничког особља

Унос са Оксфордског енглеског речника за "дебаг" наводи термин "дебаговање" употребљен код тестирања мотора авиона 1945 у Дневнику Друштва Краљевског ваздухопловства. Чланак у "Ваздушна сила" (Јун 1945 pp. 50) се такође односи на дебаговање, овог пута на камере ваздухопловства. Хоперов баг је нађен 9. септембра 1947. Термин није прихваћен од програмера све до ранијих 1950-тих. Гилијев чланак 1951 је најранија детаљна дискусија програмерских грешака, али не користе термин "буг" или "дебаговање". У АЦМ-овој дигиталној библиотеци, термин "дебаговање" је први пут коришћено у три папира из 1952 АЦМ светсих састанка. Двоје од троје користи термин у знацима навода. 1963 "дебаговање" је постало довољно често да термин буде споменут у пролазу без објашњења на првој страници CTSS приручника.

Кидвелов чланак Праћење Неухвативог Рачунарског Бага разматра етимологију "бага" и "дебаговања" у великим детаљима.

Обим

Пошто су софтвер и електронски системи постали углавном комплекснији, различите технике дебаговања су се рашириле са више метода да се детектују аномалије, процес утицаја и распоред софтверских унапређења или пуних упдејта система. Речи "аномалија" и "несразмера" се могу користити, као неутрални термини, да се избегну речи "грешка" и "дефект"или "баг" где може бити импликација да су сви назови грешке, дефекти и багови морају бити поправљени (под сваку цену). Уместо, процес утицаја може се направити да одлучује да ли промене које би уклониле аномалију(или несразмеру) би биле корисне за систем, или можда распоред нових издања може донети промене безпотребно. Нису сви проблеми критични по живот или критични за мисију у систему. Такође, важно је избећи ситуацију где промена може бити више узнемирујућа за корисниге, дугорочна, него живети са познатим проблемом (где би "лек био гори него зараза"). Заснивање одлука прихватљивости неки аномалија може избећи културни "нула-дефект" мандат, где људи могу бити у искушењу да поричу постојање проблема тако да би се резултати показали као нуле дефекти. Разматрајући колатералне проблеме, као што су цена-против-бенефита процес утицаја, онда шире технике дебаговања ће одужити проналазак фреквенција аномалија (колико ће се често исти "багови" стартовати) да би се помогло у процени њиховог утицаја над целокупним системом. 

Алати

Дебаговање на конзолама видео игара се обично ради са специјалним хардвером као што је Ексбокс дебаг срество намењен само за програмере.

Обим дебаговања, у сложености, од поправљања једноставних грешака до извршавања дугих и заморних задатака збирке података, анализе и заказаних ажурирања. Вештина дебаговања програмера може бити битан фактор у могућности да се дебагује проблем, али тежина дебаговања софтвера највише варира због сложености система, и такође зависи, у одређеној мери, од програмског језика који се користи и доступних алата, као што су дебагери. Дебагери су софтверски алати који омогућују програмеру да прати извршавање програма, да га заустави, рестартује, постави места прекида, и да измени вредности у меморији. Термин дебагер се може такође односити на особу која ради дебаговање.

Углавном, програмски језици високог нивоа, као што је Јава, чине дебаговање лакшим, зато што имају особине као што су контрола извршавања који чине праве изворе нередовног понашања лаке за приметити. У програмским језицима као што су С или асемблер, багови могу прузроковати тихе проблеме као што је корупција меморије, и може бити често тешко увидети где се првобитно проблем догодио. У тим случајевима, алати дебагера меморије могу бити потребни. 

У одређеним ситуацијама, основна сврха софтверски алата је језичка спецификација у природи и може бити корисна. Ово узима облик статичног кода анализе алата. Ови алати траже веома специфичну групу проблема, честе и неке ретке, унутар изворног кода. Сви ови проблеми детектовани помоћу ових алата би често били покупљени преко компајлера или интерпретатора, иоако они не проверавају синтаксу, али су више за проверавање семантике. Неки алати трвде да су у могућности да детектују 300+ јединствених проблема. И комерцијални и бесплатни алати се налазе и виже језика. Ови алати могу бити много корисни када се проверава велика изворна стабла, где није практично да се пролази кроз код. Типични пример детектованог проблема би била деференца променљиве која се јавља пре него што је променљивој додељена вредност. Још један пример би био да се изведе чврсто откуцавање провере када језик не захтева тако. Дакле, они су бољи у откривању грешака, него стварних грешака. Као резултат, ови алати имају репутацију лажних узбуна. Стари Ујуникс линт програм је ранији пример  .

За дебаговање електронског хардвера (нпр., рачунарски хардвер), као и ниског-нивоа софтвера (нпр., BIOS-а, драјвера) и фирмвера, интструмент као што су осцилоскопи, логички анализатори или кружни емулатори (ICE) се често користе, само или у комбинацији. ICE може да уради много типични деберских ставки софтвера на ниском нивоу софтвера и фирвера.

Типичан процес дебаговања

Обично први корак у дебаговању је покушај да се репродукује проблем. Ово може бити нетривијални задатак, на пример као што је са паралелном обрадом или неким необичним софтверским баговима. Такође, специфично корисничко окружење и коришћење историје може отежати репродуковање проблема. 

Након што је баг репродукован, можда је потребно да улаз програма буде поредностављен како би било лакше дебаговање. На пример, баг у компајлеру може довести до рушења када се анализира неки већи изворни фајл. Међутим, после поједностављења тест случаја, само неколико линија оригиналног извора фајла може бити довољан да репродукује исто рушење. Овакво поједностављење може бити направљено ручно, користећи се завади па владај приступом. Програмер ће покушати да уклони неке делове оригиналног тест случаја и провериће да ли проблем идаље постоји. Када је проблем дебаговања у графичком корисничком интервејсу, програмер може покушати да прекине неке интеракције са корисником од оригиналног описа проблема и  да провери да ли су преостале акције довољне да се појави баг.

Након што је тест довољно поједностављен, програмер може користити дебагер алатку да проучи стање програма (вредности варијабли, плус позив гомиле) и да прати порекло проблема. Алтернативно, праћење се може користити. У једноставним случајевима, праћење је само неколико иштампаних исказа, који избацују вредности варијабли у одређеном тренутку извршења програма.

Технике

• Штампање дебаговања (или праћење) је чин гледања (уживо или снимљено) трагова изказа, или штампање исказа, који показују проток извршења процеса. Ово се понекад назива и printif дебаговање, због коришћења функције printif у С. Ова врста дебаговања је укључена на захтев ТРОН-а у оригиналној верзији почетничко-оријентовано Бејсик програмирање. Трон је стајао за, "траг на". Трон је изазивао линије пројева сваке Бејсик комадне линије да штампа како је програм радио.
• Даљинско дебаговање је процес дебаговања програма који ради на више различитих система од дебагера. Да би се почело даљинско дебаговање, дебагер се конектује са удаљеним системом преко мреже. Дебагер може да контролише извршење програма преко удаљеног система и да враћа информацију његовог стања.
• Дебаговање после смрти је дебаговање програма након што се он срушио. Сродне технике обично укључују више техника праћења (на пример,) и/или анализу стања меморије(или стања језгра) срушеног процеса. Стање процеса се може прибавити аутоматски преко система (на пример, када се процес заустави због неконтролисаног изузетка) или преко програмерових убачених инструкција, или ручно преко корисника.
• "Вучја ограда" алгоритам: Едвард Гаус је описао једноставан али веома корисан и сада познат алгоритам у артиклу из 1982 о комуникацијама АЦМ: "Постоји један вук у Аљасци; како да га нађете? Прво направите ограду на средини државе, чекајте вука да залаје, одлучите се на којој страни ограде се налази. Понављајте процес само на тој страни, све док не дођете до те тачке да видите вука. " Ово је убачен пример у Гит верзији контролног система као команда git bisect, која користи алгоритам изнад да одлучи урезивање је довело до бага.
• Делта дебаговање – техника аутоматизације теста случаја једноставности.
• Стискање Сафа – техника изоловања грешке у оквиру теста користећи прогресивне инлине делове палог теста

Дебаговање уграђених система

Супротно од главне сврхе рачунарског софтверског дизајнираног окружења, примарна карактеристима угражених окружења је чист број различитих платформи доступних развојницима (CPU архитектурама, добављачима, оперативним системима и њиховим варијантама). Уграђени систему су, по дефиницији, дизајни без генералне сврхе: они су типично направљени за један задатак (или мали опсег задатака) и платформа је изабрана специјално да би прилагодила ту апликацију. Не само да ова чињеница чини живот тежим програмерима уграђених система, она такође чини дебаговање и тестирање ових система тежим такође, пошто различите алатке за дебаговање су потребне за различите платформе.

• да се идентификују и поправе багови у систему (нпр. логички и синхронизациони проблеми у коду или гречке дизајна у хардверу);
• да се скупе информације о оперативним стањима система који се можда користио за анализу система: да се нађе начин за побољшање перформанса или да се оптимизују остале битне карактеристике (нпр. потрошња енергије, поузданост, одговор у реалном времену итд. ).

Анти-дебаговање

Анти-дебаговање је"имплементација једне или више техника унутар рачунарског кода који спречава покушаје обрнутог инжењеринга или дебаговање циљаног прогреса ". Активно се користи од стране познатих издавача у заштити од копирања, али такође се користи и од стране малвера да закомпликује детекцију и елиминацију. Технике које се користе у анти-дебаговању укључују:

• АПИ-заснован: проверава постојање дебагера користећи информације система
• Изузетак-заснован: проверава да ли су изузеци умешани
• Процес и навој блокови: проверавају да ли су процес и навој блокови манипулисани
• Модификован код: проверава модификације кода направљене од стране руковања софтвера дебагерових контролних тачака
• Хардвер и регистрован- заснован: проверава хардверске контролне тачке и CPU регистре
• Тајмин и кашњење: проверава протекло време приликом извршавања инструкција
• Детектовање и кажњавање дебагера

Ранији пример анти-дебаговања постојао је у ранијим верзијама Мајкрософт ворда који, ако је дебагер детектован, избацује поруку која каже:"Дрво зла носи горке плодове. Сада шлајфујем програмски диск", после чега то проузрукује флопи диск драј да емитује буку аларма што има намеру да уплаши косника да поново проба то.

Литератра

• David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, AMACOM. 2002. ISBN 978-0-8144-7168-5.
• Bill Blunden: Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code, APress. 2003. ISBN 978-1-59059-234-2.
• Ann R. Ford, Toby J. Teorey (2002). Practical Debugging in C++. Prentice Hall. ISBN 978-0-13-065394-9. 
• Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka, The Developer's Guide to Debugging, Second Edition, Createspace. 2012. ISBN 978-1-4701-8552-7.
• Robert C. Metzger (2003). Debugging by Thinking: A Multidisciplinary Approach. Digital Press. ISBN 978-1-55558-307-1. 
• Glenford J Myers: *The Art of Software Testing, John Wiley & Sons inc. 2004. ISBN 978-0-471-04328-7.
• John Robbins (2000). Debugging Applications. Microsoft Press. ISBN 978-0-7356-0886-3. 
• Matthew A. . Telles, Yuan Hsieh: The Science of Debugging, The Coriolis Group. 2001. ISBN 978-1-57610-917-5. 
• Dmitry Vostokov: Memory Dump Analysis Anthology, Volume 1, OpenTask. 2008. ISBN 978-0-9558328-0-2.
• Andreas Zeller: Why Programs Fail, Second Edition: A Guide to Systematic Debugging, Morgan Kaufmann. 2009. ISBN 978-0-12-374515-6.
• Artzi, Shay; Kiezun, Adam; Dolby, Julian; Tip, Frank; Dig, Danny; Paradkar, Amit; Ernst, Michael D. (2008). „Finding bugs in dynamic web applications”. Proceedings of the 2008 international symposium on Software testing and analysis. стр. 261—272. ISBN 9781605580500. S2CID 13180030. doi:10.1145/1390630.1390662. hdl:1721.1/40249. 

Спољашње везе

• Crash dump analysis patterns – in-depth articles on analyzing and finding bugs in crash dumps
• Learn the essentials of debugging – how to improve your debugging skills, a good article at IBM developerWorks (archived from the original on February 18, 2007)
• Plug-in Based Debugging For Embedded Systems Архивирано на сајту Wayback Machine (10. децембар 2019)
• Embedded Systems test and debug - about digital input generation – results of a survey about embedded system test and debug, Byte Paradigm (archived from the original on January 12, 2012)