Skal vi lave en mini-konference om debugging?

Som I nok ved har jeg i mange år været med til at lave Linuxforum/Open Source Days konferencer i et fantastisk team.
Forrige år lavede min gode ven Kenneth Geisshirt og jeg Emacsforum-konferencen - lille, sjov og markant nemmere at arrangere.
I samme "mindre" niveau vil jeg gerne lave en konference med fokus på "Debugging med Linux/BSD".

Min pointe er at "debugging" bare ikke læres på universiteterne - og det er skammeligt. Jeg har skrevet om dette tidligere.
Derfor må vi samles fra tid til anden og udveksle erfaringer - og i denne kontekst UNIX/Linux/BSD-værktøjer. Jeg forestiller mig, at det med fordel kan blive en dag, hvor der lægges vægt på hands-on erfaringer, praktiske teknikker, og gerne focus på værktøjer, der kan hjælpe til at finde fejl automatisk.

Jeg forestiller mig, at der kommer 50-100 Linux/BSD folk og meget gerne jer, som har "skidt på hænderne". Jer som har debugget grimme ting, som har lært en masse af det og gerne vil præsentere hvordan I kom igennem, så andre kan lære af det.
Eventen kan vi holde i september eller lignende, omkring København - gratis - enten hos et firma eller på en læreanstalt. Hvis I har lyst til at være vært for det - skriv til mig :-)
Hvis der kommer begræsninger på antal sæder, så bliver det "bedste foredrags-bidrag" kommer først ind.

Lad mig endda lave et eksperiment af de sjove:

  • Grov-planlægningen kan ske (indtil videre) i et Google-dokument, jeg har delt.
  • Egentlig diskussion kan f.eks. nedenfor eller på min Google+ profil
  • Det som er meget vigtigt de næste par uger er at få lavet nogle grove rammer for et dagsprogram, og hvis I kan og vil bidrage, så skriv jer på eller stik mig en email om det .

Er I friske?

/pto

Kommentarer (50)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Rasmussen

Vil brug af automatisk test integreret i gits commit procedure kunne karakteriseres som en form for debugging?

I et nyt projekt, jeg deltager i, har vi indarbejdet automatisk integrationstest i gits commit procedure som en del af continues integration. Ideen er, at for samtlige komponent interfaces gælder, at disse skal have et sæt af unit tests tilknyttet, og når der committes til git, vil git automatisk afvikle samtlige tests for alle komponenter inden, en commit kan foretages.

Martin Bøgelund

No offense - men er debugging ikke mest for folk der ikke kan kode ordentligt?

Helt for egen regning vil jeg påstå at debugging er tests og designs grimme fætter, og at det derfor ikke er i fokus på læreanstalterne.

Hvis man designer sit stads ordentligt, er lidt omhyggelig med sin modularisering, har noget god kodepraksis hvor man får får ting der er forkerte til at se forkerte ud ("make wrong code look wrong"), og iøvrigt har nogle solide tests der viser at ens moduler gør det man beder dem om, så er debugging ikke fyldigt nok til at være en selvstændig diciplin.

... det var lidt tankegangen da jeg havde datalogi på universitetet. Fokus på design og test (og dermed kravspecs), og ikke andet end "debuggeren finder I her, hvis I har for vane at lave fejl" når det kom til debugging.

Nu var det også mest højniveau (objektorienterede) sprog man kylede efter os. Den smule erfaring jeg har med C (som jo nok er det der er jeres omdrejningspunkt), siger mig at C er kropumuligt at kode i efter devicen "make wrong code look wrong". Når C-programmører skal spille hårde overfor hinanden, er det jo noget med at vise hinanden noget minimalistisk og dybt kryptisk kode, som gør noget rasende smart, men som er helt umuligt for gennemsnitsprogrammører at gennemskue.

Jo tak, fordi I skal vise jer overfor hinanden, får vi noget kode der er kropumuligt at fejlfinde i og vedligeholde for den næste programmør, som måske ikke har jeres evner. Så hvis målet er jeres personlige jobsikring, er det da måden at gøre det på.

Og så kan jeg godt forstå at debugging bliver en stor diciplin...

Var det ikke en idé at få lidt input fra Anne Mette Hass fra bloggen om test og kravspecifikationer æltet ind i denne dej? Og så en Version2-blogger der kan sige noget fornuftigt om design (så vidt jeg kan se er der ingen V2-blog rettet specifikt mod design)?

Og igen - No offense! Selvom det måske ligner kritik af værste skuffe, så er det konstruktivt ment. Debugging er jo ret beset en uønsket aktivitet - det man ønsker er jo at lave noget kode der duer i første hug, og alternativt er til at fejlfinde i blot ved at kigge koden igennem eller køre en simpel test.

Så sagt med andre ord: Sidder man og opdager at man er blevet utroligt dygtig til at debugge, bør man overveje om man ikke hellere skulle smide ressourcer efter proaktivt at lave noget kode man har styr over og som virker, fremfor at jagte bugs i noget kode, som man åbenbart ikke har styr over.

Jeg har stillet den store spand frem, som kan indeholde downvotes, men jeg vil foretrække hvis I kan motivere og argumentere for hvorfor der skal så stor fokus på debugging - rent akademisk kan jeg ikke se det giver mening.

Andreas Bach Aaen

Det kunne være fint med et indlæg om Coccinelle, som man kan bruge til at finde flere at samme type fejl når man har fundet den første.

Omkring fejlfinding, så er der også hele analyse tilgangen til problemet før man vælger værktøjer.
Vi fik en gang sidste år en fejl rapportret fra en af vores kunder. Fejlen kom med måneders mellemrum. Ingen ande de mange andre kunder der benytter samme software har oplevet fejlen.
Det væsentligste input til at finde fejlen var hyppigheden. Den var kun den ene kunde der så fejlen, da de har langt større produktion end de andre kunder. Altså statistisk set kunne det fint passe at alle kunder har fejlen, men at kun een kunde havde oplevet den. Det kunne ikke være et memory leak for det ville ske langt hyppigere. Det måtte være timingsrelateret. Dette var nok til at vi kunne lave en testopstilling med delsystemet kørende på mange CPU kerner og så reproducere fejlen i laboratoriet. Slutteligt fandt vi fejlen i en driver hvor der manglde den rette sem semaforbeskyttelse af nogle variabler.

Palle Simonsen

Her: https://plus.google.com/100210281016644182390/posts/p/pub

Bla. om debugning i (F)OSS webudvikling m. MySQL, PHP, Javascript HTML(5).

@Martin: Uddannelse i formelle metoder, software engineering og programmering forholder sig til realiterene ligesom køreskoleundervisning forholder sig til at manøvrerer en fyldt, lejet familieflytter med ikke-virkende AC gennnem en italiensk by i myldretiden for at nå et fly.

Det kan godt være dit design er lige i øjet og din kodning er pletfri, men det skal integreres med noget dine kollegaer har lavet for et par år siden og/eller et bibliotek eller bedre - en oversætter - med nogle subtile fejl. Samtidig står din ikke-tekniske chef og råber noget, hvor ordet 'deadline' indgår. Det er så her man debugger for at forstå, hvorfor skidtet virker, pånær når man henter record 25-30 samt 231, 452 og 100251 fra databasen - 452 er forøvrigt magen til record 2,3,7 og 45, der jo virker - go figure :)

Helge Svendsen

Hvem siger:

1) At du har lavet koden, du skal rette fejl i?
2) At fejlen i det hele taget ligger i den kode, du skal rette i, og ikke i et andet system, hvortil der er interface?
3) At fejlen ikke er opstået som følge af ændringer i 3 parts libraries, operativ systemer eller databaser.

Debugging er et af de mest brugbare værktøjer, hvis man har kode der rent faktisk bliver brugt (af andre).

Peter Makholm Blogger

Jeg er enig i at et godt design kan være med til at reducere mængden af fejl i koden. Jo bedre design, jo mindre spillerum er der til fejl der opstår på grund af forkerte implicitte antagelser.

Men jeg er ikke enig i din din opfattelse af test i forhold til debugging. Skal jeg være lidt fræk, så vil jeg påstå at test kun fanger indlysende fejl. Så hvis man kan nøjes med tests så er alle ens fejl indlysende.

Desuden er tests ofte kun den lette del af processen. Det handler bare om at opdage at der er en fejl, debugning går skridtet dybere og forsøger at forklare hvorfor der er en fejl og hvordan den rettes. Hvis man ikke er parat til at gå dette ekstra skridt, så kan man vel lige så godt droppe overhovedet at teste sit program.

Kort sagt: Debuggen er den process man begynder når ens tests siger at der er et problem. Og efter man har debugget sig til hvorfor man har et problem er det selvfølgelig indlysende og så bør man kunen teste automatisk for det.

Grænsen mellem de to aktiviteter er selvfølgelig flydende. I et vist omfang er debugning ofte "bare" at skrive flere tests. Regressionstests er så kunsten at vælge hvilke af disse tests man bør beholde efterfølgende.

Mads Bahrt

Dit indlæg forudsætter at der er tale om nyudvikling. Jeg kan ikke lige huske hvad kilden er, men jeg er en gang blevet udsat for den påstand at størstedelen af kodearbejde er vedligeholdelse af eksisterende systemer. Hvad hvis du skal arbejde med et 10, 20, 30 eller 40 år gammelt system hvor arkitekturen er ikke-eksisterende og den hyppigst forekommende instruktion er "G***-ordet"? Så hjælper det dig ikke særligt meget at sætte dig over i hjørnet og rokke frem og tilbage imens du messende gentager: "Det ville ikke være nødvendigt at debugge hvis arkitekturen var i orden."

Pointen er at det er ikke alt kode du skal arbejde med du selv har skrevet eller endda at nogen der stadig arbejder i firmaet har skrevet.

I øvrigt kan man også sagtens lave javakode med en voldsom accidental kompleksitet, det er bare nemmere i C.

Carsten Hansen

Jeg er ikke helt klar over forskellen på preventiv og anti debugging. Google har ikke rigtigt hørt som Preventiv debugging før :-)

Er det anti-debugging som f.eks. følgende Windows link:
http://www.symantec.com/connect/articles/windows-anti-debug-reference

eller lave programmer, der er lette at debugge som f.eks:
http://www.cprogramming.com/debugging/debugging_strategy.html

Personligt foretrækker jeg mange meget simple if-sætninger. Ofte er det nok at køre en profiler for at finde fejlen.

NB:
Bliver der snart frigivet nogle slides/videos fra Open Source Days 2013?

Donald Axel

Jeg synes det er en rigtig god ide!
Det har også undret mig, at man ikke underviser i debugging m.v. på universiteternes IT-uddannelser (jeg kender kun RUC, men jeg kunne regne ud at det var det samme andre steder).

Må jeg have lov at bruge denne invitation i DK-uug Nyt blad nr. 171 (som snart skal laves færdigt)?

Ivan Skytte Jørgensen

Jeg kan se i dit dokument at du har listet "LLVM - deres statiske kodeanalyzer."
Til dagligt bruger jeg Flexelint - ville det være interessant? (ganske vist payware men meget billigt i forhold til insure++/fortify/...)

Det kunne også være interessant med en gennemgang af systemværktøjer til at debugge i et produktionsmiljø (pstack, pstree, strace, ltrace, lsof, ...)

Martin Bøgelund

Du mener ligesom "Gud skabte heltallene, resten er menneskeværk" ?

Nej, mere henad ligesom våde analogi-skruetrækkere.

Debugging er et fact of life, om ikke andet fordi folk rammer de forkerte taster når de er søvnige om morgenen eller hvis kaffe-indholdet i deres blod er udenfor tolerance.

Nu var min påstand ikke at debugging burde være ikke-eksisterende - blot at jeg er blevet skolet i at det ikke burde kunne fylde nok til at udgøre et selvstændigt akademisk emne.

Og da slet ikke, hvis det bedste du kan diske op med er slåfejl.

Martin Bøgelund

1) At du har lavet koden, du skal rette fejl i?

Den har jeg lige adresseret - det gælder om at have styr over den kode man roder med, uanset om det er ens egen eller Ruder Konges.

2) At fejlen i det hele taget ligger i den kode, du skal rette i, og ikke i et andet system, hvortil der er interface?

Det er en rigtig god pointe. Det er også der jeg af erfaring ser den største anvendelighed af debugging.

Det er dog tilpas sjældent jeg er rent ind i den situation, så det kan godt være at mit indlæg bærer præg af at jeg er forvent med at spille bold op ad kvalitetssoftware.

Jeg vil mene idealsituationen som vi bør søge hen imod er at blive bedre til at lave kvalitetssoftware, fremfor at acceptere lav kvalitet, og så brænde al produktiviteten af på at rende rundt og klaske hinandens bugs.

Måske er tilgangen for akademisk, men debugging er ikke værdiskabende som sådan, og fokus bør være på at forhindre det i stedet for at blive verdensmestre til det.

Altså mere fokus på at gøre de rigtige ting, fremfor at gøre debugging rigtigt.

3) At fejlen ikke er opstået som følge af ændringer i 3 parts libraries, operativ systemer eller databaser.

Det er vist en variation af 2)...

Debugging er et af de mest brugbare værktøjer, hvis man har kode der rent faktisk bliver brugt (af andre).

Opfattelsen af at jeg er imod debugging er forfejlet - jeg debugger jævnligt, og det er en helt nødvendig diciplin. Men slet ikke i det omfang som der lægges op til her.

Og idealsituationen er ikke at bruge kræfterne på at debugge, men på at lave og levere noget ordentligt software - og her er der altså langt mere perspektiv i design og test.

Martin Bøgelund

Jeg er enig i at et godt design kan være med til at reducere mængden af fejl i koden. Jo bedre design, jo mindre spillerum er der til fejl der opstår på grund af forkerte implicitte antagelser.

Helt enig

Men jeg er ikke enig i din din opfattelse af test i forhold til debugging. Skal jeg være lidt fræk, så vil jeg påstå at test kun fanger indlysende fejl. Så hvis man kan nøjes med tests så er alle ens fejl indlysende.

Enig.

Desuden er tests ofte kun den lette del af processen. Det handler bare om at opdage at der er en fejl, debugning går skridtet dybere og forsøger at forklare hvorfor der er en fejl og hvordan den rettes. Hvis man ikke er parat til at gå dette ekstra skridt, så kan man vel lige så godt droppe overhovedet at teste sit program.

Delvis enig.

Du tester for at vise at dit program opfører sig i overensstemmelse med specifikation og design.

Betragt det som et laboratorieforsøg for at påvise din påstand om, at dit program virker i henhold til spec/design.

Du laver heller ikke laboratorieforsøg, fordi du forventer at tyngdekraften er gået i stykker, eller fordi du forventer vand er blevet uhyre brændbart. Du gør det for at underbygge en hypotese.

Men ja - hvis din test viser at din hypotese ikke holder, må du jo i gang med at kigge kode igennem. Hvis det ikke er lykkedes at få forkert kode til at se forkert (nok) ud, er der debugging for resten af pengene.

Nogle har sikkert tendens til at fare direkte i debuggeren.
Jeg finder derimod den mentale øvelse i at køre koden i wetware meget mere givende:
-Man tilegner sig koden langt bedre (apropos den fejlslutning om at jeg antager at man selv er forfatter til koden, ovenfor).
-Man bliver uafhængig af om compiler, "runtime environment", hardware og debugger fungerer korrekt. Man er kun afhængig af sin egen abstraktionsevne - en evne som iøvrigt forbedres jo mere den trænes, og som kan bruges i ufatteligt mange andre sammenhænge end kodning.

Kort sagt: Debuggen er den process man begynder når ens tests siger at der er et problem. Og efter man har debugget sig til hvorfor man har et problem er det selvfølgelig indlysende og så bør man kunen teste automatisk for det.

Ja - eller efter kodelæsning/kørsel i wetware. Se iøvrigt ovenfor.

Grænsen mellem de to aktiviteter er selvfølgelig flydende. I et vist omfang er debugning ofte "bare" at skrive flere tests. Regressionstests er så kunsten at vælge hvilke af disse tests man bør beholde efterfølgende.

Enig. Jeg håbede at "grim fætter" indikerede en form for familierelation mellem disse aktiviteter.

Martin Bøgelund

Debugging er også for opgaver, hvor det er umuligt at forudsige alle fejlkilder på forhånd. F.eks. i forbindelse med kommunikation med eksterne blackbox-enheder.

Man kan aldrig teste i bund, eller designe robusthed overfor alle tænkelige og utænkelige eksterne parametre - Enig.

Men når du debugger står du med en konkret fejl, dvs en af dine antagelser i koden/designet/specifikationen ikke holder. Og så er det nok så værdifuldt lige at repetere disse antagelser for at se om man rent kognitivt kan gennemskue om de holder under et ændret verdensbillede.

Simon Shine

Jeg håber, der er nogen som føler sig inspireret til at snakke om nogle af følgende emner. :-)

Valgrind og memory profiling i forskellige sprog (gerne .NET, Haskell, Erlang), git commit hooks, Coccinelle, anvendelse af quickcheck i erhvervslivet (hvis det findes?), og meget gerne nogle succesfulde erfaringer fra erhvervslivet om hvordan man vender en virksomhed til at lave afprøvning -- hvordan man måler den økonomiske gevinst, hvad der skulle til for at ændre kulturen på alle niveauer i virksomheden.

Simon Shine

Hej Sune

Det synes jeg fremgår af Peters oprindelige blogindlæg: Et oplæg for folk som ikke har lært at bruge debugging til dagligt, gerne hvor oplæg holdes af folk som har erfaring. Synes du at brainstormen i kommentarerne antyder at et andet slags oplæg ville ende med at blive afholdt?

Helge Svendsen

Den har jeg lige adresseret - det gælder om at have styr over den kode man roder med, uanset om det er ens egen eller Ruder Konges.

Du har vist ikke prøvet at arve kode, der er lavet af Indiske offshore udviklings ressourcer :-D

Der er ikke styr på noget som helst.

Jeg er for så vidt enig i din tilgang med testdreven udvikling, men der kan jo også være fejl i en testcase. Derfor vil test ikke kunne erstatte debugging.

Det er slutteligt den måde man finder frem til, om det er testen eller koden, der er fejlbehæftet.

Peter Toft

Jeg er kommet lidt i tvivl om - er målet at lære nye folk at debugge eller er holde hyggearrangement for den gamle garde?

For så vidt er begge "forkerte". Mit motiv er at folk, der kan debugge deler erfaringer. Naturligvis gerne også dele til andre, der gerne vil lære.

Det er ikke min ide at vi bare skal mødes og have en kop øl/kaffe.
Det er selvfølgelig hyggeligt, men det er ikke det primære.

Povl H. Pedersen

De steder hvor jeg synes det trækker flest tænder ud at debugge er, når fejlen viser sig at være i noget af den standard funktionalitet / system libraries som man normalt antager er velfungerende. Specielt når fejlene er inkonsistente.

Man kan ikke have styr på hele kode-stacken. Og slet ikke på andre maskiner, hvor der måske er en patch mere eller mindre.

Ivo Santos

Jeg ved skam godt hvor vigtigt der er debugge, eller blot fejlfinding på dansk, hvilken det vel egentlig handler om.

Jeg ved godt at C programmering stort set er fortid ligesom hestevogne og lignende ting, men!, er der noget man som programmør eller blot hobby programmør, nu er jeg ganske vist hobby programmør i fritiden, og så er det udfordringer altid en lærerig process. Jeg har i et stykke tid haft gang i et mini framework til C programmer, og der er da heller ingen tvivt at fejlfinding er godt ting, men godt skrevet kode er nogen gange bedre end fejlfinding, hvilken jeg kan give et godt eksempel på.

Sidst jeg havde gang i mit mini framework stødte jeg på et tidspunkt ind i den klassiske 'index out of bounds' fejl, jeg var 100 procent sikker på at der ingen fejl var, og det var der så heller ikke, fejlen lå i den nye kode, fordi jeg have glemt trække 1 fra bruger input hviklen resultere i index 1, som ikke eksisterede der da kun var et element i den pågældende array jeg havde fat i.

Jeg er ganske vist selvudlært programmør og administrator, men jeg vil da alligevel gerne deltage i den der mini-konference hvis det bliver til noget.

Nikolaj Brinch Jørgensen

No offense - men er debugging ikke mest for folk der ikke kan kode ordentligt?


+1

Jo det er.

Debuggeren skal man holde sig fra og bruge som last resort. Dog kan man jo have overtaget noget forfærdelig skrammel uden tests, der er den uvurderlig. Men jeg ser også alt for ofte folk der udvikler i debuggeren!!!

Den er til nedrivning af forkert byggede elementer så nye kan opføres korrekt. The right tool for the job. Unit tests mv. finder fejl i dag, ikke debuggeren. Den leder til at fejl rettes forkert.

En ofte set (af mig) practise er at debuggeren bliver brugt til at lokalisere en anormalitet, som så rettes med nogle betingede instruktioner, der tager højde for netop den tilstand programmet har opnået. Problematikken er dog oftest at det er fordi at de antagelse man havde gjort sig om hvordan verden hænger sammen, ikke holder vand og derfor må man "tegne" et nyt billede. Det sker bare ikke, man hacker bare løs i debuggeren til det bliver holdt sammen af ølkapsler, elastikker og tyggegummi.

Log ind eller Opret konto for at kommentere