längsta tid du spenderat på att rätta en bugg?

Någon timme på programmering A lektionen i skolan )

Får väl vara den första att ge det vanliga svaret: race condition i nätverkskod, en sån här "Heisenbug". Denna berodde delvis på användning av kodordet volatile i C++, som faktiskt inte är så användbar i det fallet. Se http://software.intel.com/en-us/blogs/2007/11/30/volatile-alm...

Att upptäcka och fixa tog många dagar.

Min längsta tid för att lokalisera en bugg är nog 3-4 veckor heltid, dock så var det inte i kod som jag själv hade skrivit, men jag vill gärna beklaga mig lite i alla fall, hoppas det är ok :-).

Det visade sig att det var en assemblerinstruktion i någon intern minneshanteringsfunktion i linux-kärnan som var felaktig för just den ARM-arkitektur som programmet kördes på, vilket resulterade i att barnprocesser kunde skriva över sin föräldraprocess minne om man hade otur. Som tur var hittade jag (efter ca 2 veckor) ett sätt att reproducera en seg-fault med 100% sannolikhet, därefter kunde jag efter en hel del gdb:ande se exakt när det aktuella minnet skrevs sönder. Sedan blev det "printk"-debugging av kärnan tills jag såg exakt vilken kodrad det var som gjorde fel.

Har suttit en 2-6 timmar med php-fel. Småfel mestdels. Exemeplvis när man letar sig blå och hittar att man skrivit "=" istället för ".=" i variblar osv.
Anatar att det är så det är att vara nybörjare, även om jag skriver 100 gånger mer rätt kod nu än i början.

eqez, nu råkade jag göra något med ditt användarnamn... Kom upp någon "eqez har lagts till ... ... ????", vet inte vad det var...

Beror ju på hur man ser det. Löste förra veckan en bugg som besvärat mig i säkert två månader. Men då har jag ju inte arbetat aktivt med den mer än funderat lite då och då vad tusan som kunde ligga bakom den.

Senaste riktigt dryga bugg jag hanterat var när c++-komplatorn genererade kod olika beroende på en enum:

enum{
    FOO = <someval>,
};

hade ändrats till

enum{
    FOO = <someval>,
    VAR = -1,
};

Detta gjorde att

{
    floatarr[i]  = FOO * intvar;
}

genererade annorlunda kod. FOO bytte plötsligt typstorlek och började overflowa och generera trasiga värden på ett ställe som inte var helt lätt att hitta. Explicit cast till float löste det.

Tog nog inte mer än en vecka att hitta

Spenderade typ 3 veckor med att felsöka mitt lua-bibliotek för awesome>mpd... helmysko bugg verkligen. Använde jag libbet så hängde sig awesome. Använde jag det i ett hemmasnickrat script hängde sig scriptet. Sen upptäckte jag att jag hade gjort en typo och skrivit recieve där det skulle varit lrecieve. Då blev jag lite ledsen faktiskt

satt i en tre fyra timmar här om veckan med en liten javagrej. Hade en array med int:ar som jag skulle plocka ur och använda i en funktion men fick invalid argument exception och krash hela tiden. Kom till slut fram till att jag skickade in for-loopens räknare i funktionen istället för en int ur arrayen. Väldigt klumpigt och väldigt tidsödande.

Räknas tiden att korrigera de problem och felaktigheter som buggen orsakat?

Den som tog längst tid är jobbrelaterad så detaljerna kommer vara få, men i det stora hela så handlade det om att föra över data till en enhet över UART men fanskapet tog inte emot allt. Det hela mynnade ner till att drivaren inte hade tillräckligt hög prioritet och att någon sur buffert inte räckte till. Låter kanske enkelt men det var väldigt klyddigt för det hände så slumpmässigt. Satt nog 2 veckor med den i trace32.

Kan inte riktigt komma på en riktigt klurig bug såhär på rak arm, känns som om dom allra flesta hittas ganska direkt om man steppar igenom koden, och det går det nästan alltid att göra när det handlar om c#/asp.net som är det jag mest sysslar med. Speciellt om man inte räknar med designproblem, sådana kan ju ta väldigt lång tid att fixa beroende på vad det gäller. Men det jag tycker man lär sig mest är väl att göra så enkla lösningar som möjligt, KISS hela vägen. Och dessutom inga svårdebuggade lösningar. Buggar kommer alltid uppstå, så det gäller att göra dom enkla att hitta och fixa. En annan sak är att inte sitta själv med dom alltför länge utan ta kollegor till hjälp om det går, då brukar det gå snabbare att hitta lösningen.

I vilket fall känns det som om det är andra sorters problem som står för dom riktigt jobbiga sakerna. Tex när man måste interagera med en extern leverantörs API och man inte kan lita på att dennes system fungerar på rätt sätt, eller saker som inte är rena utvecklingsdelar, tex hur brandväggar och liknande är uppsatta i produktionsmiljön. Bara för nån vecka sen var det tex olika filrättigheter på en fil på två servrar som borde varit samma vilket gjorde att ibland kom man åt den och ibland inte. Tack vare hur servrarna används tog det ett bra tag att hitta felet...

När vi ändå pratar om buggar, vilken är den allvarligaste bugg ni varit orsak till? Dvs den som orsakat mest problem? Iof kanske det inte är något man är så pigg på att sprida ut

Apropås hitta buggar. Har ni sett vad man kan göra med DTrace? Helt unikt och helt revolutionerande:

I looked at one customer's application that was absolutetly dependant of getting the best performance possible. Many people for many years had looked at the app using traditional tools. There was one particular function that was very "hot" - meaning that it was called several million times per second. Of course, everyone knew that being able to inline this function would help, but it was so complex that the compilers would refuse to inline.

Using DTrace, I instrumented every single assembly instruction in the function. What we found is that 5492 times to 1, there was a short circuit code path that was taken. We created a version of the function that had the short circuit case and then called the "real" function for other cases. This was completely inlinable and resulted in a 47 per cent performance gain.

Certainly, one could argue that if you used a debugger or analyzer you may have been able to come to the same conclusion in time. But who would want to sit and step through a function instruction by inctruction 5493 times? With DTrace, this took literally a ten second DTrace invocation, 2 minutes to craft the test case function, and 3 minutes to test. So in slightly over 5 minutes we had a 47 percent increase in performance.

Another case was one in which we were able to observe a high cross call rate as the result of running a particular application. Cross calls are essentially one CPU asking another to do something. They may or may not be an issue, but previously in was next to impossible (okay, really impossible) to determine their effecs with anything other than a debug version of the kernel. Being able to correlate the cross call directly to application was even more complex. If you had a room full of kernel engineers, each would have theories and plausible explanations, but no hard quantifiable data on what to do and what the impact to performance would be.

Enter DTrace.... With an exceedingly simple command line invocation of DTrace, we were able to quickly identify the line of code, the reason for the cross calls, and the impact on performance. The basic issue was that a very small region of a file was being mmap(2)'d, modified, msync(3C)'d, and then munmap(2)'d. This was basically being done to guarantee that the modified regoin was sync'd to disk.

The munmap(2) was the reason for the cross call and the application could get the same semantics by merely opening the file with O_DSYNC. This change was made and performance increased by almost double (not all from the cross calls, but they were the "footprint" that lead us down this path). So we went from an observable anomaly that previously had no means of analysis to a cause and remediation in less that 10 minutes.

Här är mycket intressant information om DTrace och Rails:
http://blogs.sun.com/bmc/entry/dtrace_on_rails

DTrace och PHP:
http://blogs.sun.com/bmc/entry/dtrace_and_php_demonstrated

Man kan använda DTrace tillsammans med andra programmeringsspråk oxå.

Vad tycker ni? Är det användbart?