zoners compileren gereedschap

Commentaren

Transcriptie

zoners compileren gereedschap
Dynamische analyse helpt bugs verder terugdringen
ITMANAGEMENT
Foutloze software komt n
Traditionele manieren van software bouwen en testen zijn niet meer voldoende
voor het creëren van kwalitatief hoogwaardige producten. Veelvuldig patchen en
bugfixen is het gevolg. Geautomatiseerde
dynamische analyse kan snel de vinger
leggen op veel onontdekte missers.
door: THIJS DOORENBOSCH / [email protected]
beeld: US AIR FORCE
G
emiddeld zit in elke 1000 regels code een fout. Dat betekent dat bijvoorbeeld in de software van de Joint Strike
Fighter zo’n 24.000 fouten zitten. Een uitgebreid testprogramma moet ervoor zorgen dat die fouten geen fatale gevolgen hebben. Maar de huidige testprocessen zijn complex
en tijdrovend. Het testprogramma van de JSF is al ernstig vertraagd,
bleek onlangs uit een gelekt memo van de afdeling Operational Test and
Evaluation van het Amerikaanse leger. De tests zouden moeten zijn afgerond voordat de toestellen in actie komen; de eerste vluchten staan
gepland voor een Britste luchtvaartshow deze zomer, waarschijnlijk
met wapensystemen aan boord.
De reactie van het F-35 Joint Program Office (JPO) op de memo is de
softwaretests helemaal te schrappen. Het gaat namelijk om een interim
release van de software voor een beperkte hoeveelheid straaljagers die
nu aan de Amerikaanse marine zijn geleverd. Voordat andere landen de
JSF geleverd krijgen, komt er nog een definitieve versie, is het argument. Die zou volgens planning op 31 juli 2017 klaar moeten zijn. Het
halen van die datum is echter ‘niet realistisch’, waarschuwt Michael
Gilmore, de leider van het testprogramma. Wanneer wel aan die datum
wordt vastgehouden, moet een significant aantal testpunten worden
overgeslagen. Worden er vervolgens in praktijk bugs geconstateerd, dan
kunnen die pas worden opgelost in een nieuwe release. Die staat pas
voor 2021 op het programma.
Het voorbeeld van de JSF is kenmerkend voor complexiteit van het ontwikkelen en testen van slimme apparatuur. Het aantal van dergelijke
embedded systemen neemt met de komst van het Internet of Things
spectaculair toe, net als de complexiteit van die systemen. Heeft de JSF
nog 24 miljoen regels code, de Mercedes S-klasse bijvoorbeeld, heeft al
meer dan 100 miljoen regels code aan boord. Hoe kan dat? Omdat de JSF
om te beginnen geen entertainmentsysteem aan boord heeft. Een beetje webbrowser is al snel goed voor zo’n 8 miljoen regels code.
Niet meer te overzien
16
Foutloos.indd 16
Een goede ontwikkelaar kan hooguit 10.000 regels code overzien, veel
te weinig om alle fouten uit software te halen. Een bijkomend probleem
is dat software steeds vaker op multicore processors wordt uitgevoerd,
ook in embedded toepassingen. Dat maakt een nieuw type fouten mogelijk dat lastig te traceren valt. Want naast de fouten in het proces zelf,
krijg je ook te maken met missers in de synchronisatie van de verschillende processen. Doordat de ene kern wat achterloopt op de andere,
probeert de eerste bijvoorbeeld een tussenuitkomst uit het geheugen te
lezen op een plek waar de tweede die nog niet heeft geschreven.
Het gevolg is dat de eerste iets leest dat in een eerder proces op die
geheugenplek is geschreven. Doorgaans is dat non-informatie voor
het betreffende proces, dat als gevolg daarvan crasht. Een dergelijk
probleem kan ook een beveiligingslek creëren.
Een oplossing voor deze zogeheten ‘race condities’ is het plaatsen van
een ‘stoplicht’ op zo’n kritieke plek in de code. Een ‘stoplicht’ kan echter weer aanleiding zijn voor een andere typisch probleem van parallelle
verwerking: de deadlock. In dat geval ontstaat een situatie waarin verschillende processen die van elkaar afhankelijk zijn, op elkaar blijven
wachten en het geheel stilvalt.
Heisenbugs
Of zo’n probleem bij parallelle verwerking optreedt, is afhankelijk van
het functioneren van de verschillende kernen. Het kan heel goed zijn
dat een bug zich maanden niet voordoet, maar op eens toeslaat – bijvoorbeeld door een externe factor die een van de kernen vertraagt. Na
een herstart kan de bug weer tijden niet optreden. Zo’n slecht reproduceerbare bug wordt ook wel een Heisenbug genoemd, naar de kwantummechanica-specialist Heisenberg. Die beargumenteerde voor het
eerst dat eigenschappen van een kwantumdeeltje soms wel en soms
niet kunnen worden vastgesteld. “Heisenbugs zijn een bekend fenomeen waar al heel veel werk aan is gedaan”, zegt Frits Vaandrager, hoogleraar binnen de afdeling Software Science aan de Radboud Universiteit.
“Ze zijn moeilijk te vinden en de zoektocht levert veel false positives
op, fouten die eigenlijk geen fout blijken te zijn.”
Drie oplossingen
Een veelbelovende oplossing voor dit probleem is het inzetten van modelgedreven softwareontwikkeling. De architecten en ontwikkelaars
stellen alleen een ontwerp op en de code wordt vervolgens door een
machine gemaakt. In de praktijk blijkt echter vaak dat je niet alle code
zo maar weg kan gooien om opnieuw te beginnen. Juist die verse start is
10-03-16 11:02
nu wel heel dichtbij
De software van de Joint Strike
Fighter is nog steeds niet bugvrij.
Onlangs bleek dat piloten van de
JSF tijdens de vlucht soms de
radar moeten herstarten om deze
te kunnen blijven gebruiken.
mogelijk bugvrij te krijgen.” Dat gereedschap is echter ontwikkeld voor
wetenschappelijke doeleinden en niet goed bruikbaar in de praktijk van
softwareontwikkeling op commerciële basis, zegt Tobias Kuipers van de
Software Improvement Group (SIG). “Het is niet fair een vergelijking te
maken met commerciële tools”, beaamt Vaandrager. “Voor model checking bijvoorbeeld is zeer specifieke expertise nodig, die in een commerciële setting dikwijls niet voorhanden dan wel te duur is.”
Een meer recente aanpak is de inzet van gereedschap dat de programmeur helpt te analyseren hoe zijn software op de hardware draait, de
zogeheten dynamische analysetools. Dit gereedschap analyseert de
werking van de software terwijl deze wordt uitgevoerd op de hardware.
Er wordt een nieuwe compilatie gemaakt waarbij aan de te testen software extra informatie wordt toegevoegd om het gedrag van de software
te traceren. Op die manier kan de tool nagaan op welke punten in de
van elkaar afhankelijke threads het fout gaat en aangeven waar de
oorzaak ligt. Maar ook deze gereedschappen zijn niet erg geschikt
voor gebruik bij de ontwikkeling van productiesoftware.
Dynamische analyse
TOYOTA’S GAVEN ZELF GAS
De kwaliteit van embedded software wordt steeds belangrijker. Wanneer internetbankieren even uit de lucht is, levert dat hooguit commotie en ergernis op. Hoe anders is het wanneer een JSF opeens niet
meer wil optrekken na een duikvlucht. Of een auto onverwachte dingen gaat doen, zoals Toyota overkwam in 2009. De auto’s gaven op
onvoorziene momenten opeens vanzelf vol gas: het gevolg van een
Heisenbug. Daarvan zaten er meer in de software, zo bleek uit een
vernietigend exern kwaliteitsrapport. Het herstel heeft Toyota een
miljard dollar gekost.
Het probleem wordt groter doordat embedded software uit concurrentie-overwegingen steeds sneller klaar moet zijn en bovendien lastiger te onderhouden is. Een clouddienst als Spotify levert soms wel
twee keer per dag een update en komt een keer per maand met een
grote bugfix-veegactie. Dat zal met embedded software niet snel
gebeuren; veel dingen waaruit het Internet of Things bestaat, hebben
een draadloze verbinding met onvoldoende capaciteit voor een
remote update. Daarmee neemt de druk op het produceren van
foutloze of op zijn minst foutarme software steeds verder toe.
Het Nederlandse startersbedrijf Vector Fabrics heeft zich er daarom op
toegelegd het gebruik van deze dynamische analysehulpmiddelen zo
makkelijk te maken dat ze een vaste plek krijgen in ontwikkeltrajecten.
Het startte in 2007 met de bouw van gereedschap dat ontwikkelaars
helpt bestaande software die is ontwikkeld voor processoren met een
enkele kern, geschikt te maken voor parallelle verwerking. Gaandeweg
werden geautomatiseerde dynamische testmethoden ontwikkeld om
de typische problemen met parallelle verwerking te detecteren en op te
lossen. Die zijn nu gebundeld in Pareon Verify.
“Met een druk-op-de-knop-analyse moet het gebruik van deze testmethode in een continous integration test standaard meegenomen kunnen worden. Een geautomatiseerde dynamische analyse kan in een enkele run fouten aangeven, waar het handmatig zoeken naar de oorzaak
vaak een maand kan kosten”, zegt CEO Martijn Rutten van Vector
Fabrics. “De rapportage geeft aan welke fouten waar optreden en geeft
aan waar de root cause zit. Die kan soms op een heel andere plek in het
proces zitten dan waar het probleem optreedt.” Pareon Verify is sinds
oktober op de markt. Rutten zegt inmiddels veel belangstelling te hebben vanuit de hele wereld, van machinebouwers tot smartphoneproducenten. Ingenieurs- en innovatieadviesbureau Altran bijvoorbeeld gebruikt Pareon Verify al op een embedded TCP/IP-stack. Het dynamische
analysegereedschap vindt allerlei Heisenbugs die de statische analysetool en unit tests die Altran in gebruik heeft, laten liggen.
Foutloos is een illusie
de enige manier waarop modelgedreven ontwikkeling het aantal fouten
fors kan terugdringen. De meeste embedded software bevat toch legacy
en die is bewezen niet bugvrij. Wellicht kunnen die oude codeonderdelen
ooit vervangen worden, maar voor de korte termijn is modelgedreven
ontwikkeling meestal geen pasklare oplossing.
Controle van de software is een betere optie. Voor een betere grip op de
kwaliteit van handmatig gecodeerde software is veel gereedschap beschikbaar. Het meeste daarvan laat zich vangen onder de term statische
analysetools. Die lopen de regels na op afwijkingen van kwaliteitsstandaarden en andere bekende missers. Je kunt daarmee echter niet analyseren waar het programma verbindingen heeft tussen geheugenplekken. Ook levert het gereedschap veel false positives op. De reactie van
de toolontwikkelaars is vaak de paden af te sluiten die te veel false positives geven. Dat heeft weer tot gevolg dat gemakkelijk fouten over het
hoofd worden gezien, de false negatives. Vaandrager: “Er zijn inmiddels
een paar zeer krachtige statische analysetools ontwikkeld, bijvoorbeeld
Coverity. Ook zijn er de modelcheckers, zoals Spin. Dat is ontwikkeld
door de van oorsprong Delftse computerwetenschapper Gerard Holzmann. Hij gebruikt dit gereedschap tegenwoordig samen met een batterij andere tools om bijvoorbeeld de software voor marslanders zoveel
Foutloos.indd 17
Hoe waardevol het gereedschap is, zal vooral in praktijk moeten blijken,
waarschuwt Kuipers. “Het probleem is dat er niet zoiets bestaat als een
silver bullet. Voor het opsporen van fouten is altijd een mix van statische en dynamische tools nodig. Programmeurs zijn daarbij vaak erg
eigenzinnige mensen. In het algemeen willen ze wel wat uitproberen,
maar nieuwe tools moeten wel aansluiten bij hun werkwijze anders laten ze het al snel links liggen.” Vaandrager noemt de tool Pareon Verify
interessant, maar wijst eveneens op het belang van de inzet van een
mix van statische en dynamische tools. Rutten bevestigt dat: “Je hebt
beide nodig als je serieus bent over kwaliteit. Pareon maakt het verschil
met bestaande dynamische tools in de aansluiting bij de huidige werkwijze en uitdagingen: race condities al vroeg herkennen als onderdeel
van continuous integration.”
Kuipers vraagt zich af of het schrijven van volledig foutloze software
niet een illusie is. “Zo lang componenten voldoende zijn geïsoleerd, kun
je ze snel genoeg herstarten. In sommige kritieke systemen (bijvoorbeeld automatische piloten) wordt elke component meerdere keren per
seconden gecheckt op deadlocks. Indien nodig wordt zo’n component
dan binnen een milliseconde opnieuw opgestart. Dat is mathematisch niet fraai, maar het werkt wel.”
»
17
10-03-16 11:02

Vergelijkbare documenten