Intel Skylake og Kaby Lake processorer indeholder en noget usædvanlig fejl, som kan udløses, når man afvikler kode med meget korte løkker og bestemte registertyper. Men det var sin sag at finde frem til, at fejlen lå i processoren.
Det var formentligt Xavier Leroy, udvikler på OCaml, som først opdagede fejlen. I et blogindlæg beskriver han, hvordan en virksomhed, som brugte OCaml havde problemer med at køre version 4.03 af programmeringssproget. Når de havde compilet deres kode og afviklede programmet, oplevede de af og til, at det crashede.
OCaml tilhører ML-familien af programmeringssprog med et stærkt typesystem og garbage collection. Brugeren, som rapporterede fejlen, oplevede kun problemer på Skylake-baserede maskiner og kun med programmer skrevet i OCaml.
OCaml er selv skrevet i C og bruger som regel GCC-compileren, og brugerens mistanke var, at der måtte være en fejl i C-koden bag OCaml.
Problemet var, at fejlen opstod tilfældigt. Det var ikke ved hver afvikling, og det var ikke på præcis samme måde. OCaml og GCC kunne meget vel have genereret kode med en fejl, men i så fald ville det være en deterministisk fejl - altså den samme fejl hver gang.
Ved analyser af 30 crashes fandt Xavier Leroy fejlen 7 forskellige steder, og det var sket både i selve applikationen og i OCamls garbage collection. Fælles for dem var, at en pointer i OCamls heap ikke pegede på det rigtige sted.
Det var sådan set ikke en usædvanlig type fejl, hvis der var en fejl i OCaml, men problemet var, at fejlen ikke var forudsigelig. Derfor satte Xavier Leroy sig for at tage muligheden for en hardwarefejl alvorligt.
Han kørte en række af tests på brugerens Skylake-system og forsøgte blandt andet at køre en række udgaver af programmet parallelt for at se, om der var en sammenhæng mellem belastning eller hukommelsesforbrug. Det ville kunne afsløre, om der eksempelvis blot var tale om en fejl udløst af for høj temperatur på systemet.
Men i stedet for, at fejlene blev mest hyppige ved maksimal belastning, så viste der sig at være et spring mellem 2 og 4 processer. Den pågældende maskine havde en processor med 4 fysiske kerner, og to af dem var i forvejen i brug til andre processer. Den pågældende applikation var enkelttrådet, og styresystemet ville normalt fordele processerne på de fysiske kerner.
Forskellen mellem 2 og 4 processer var, at her slog HyperThreading til. Det er en funktion, som deler den fysiske kerne op i to. Der kunne altså være en sammenhæng mellem de uforudsigelige crashes og HyperThreading.
Nye problemer
Xavier Leroy nåede frem til en simpel løsning: Slå HyperThreading fra. Det forklarede ikke den underliggende fejl, men løste problemet for den pågældende bruger. Det skete i 2016.
Hos Ahref fik en kunde senere i 2016 et tilsvarende problem. OCaml-kode blev compileret med tilfældige fejl, skriver Joris Giovannangeli fra Ahrefs i et blogindlæg.
Det blev særlig problematisk, da koden, som kørte på en klynge af Intel Skylake-processorer, begyndte at generere fejl, som endte med at beskadige data på storagesystemet.
Også her var mistanken først en fejl i softwarestakken, hvor først virtualiseringslaget og derefter OCaml blev undersøgt. Alle fejlene havde at gøre med adresser i hukommelsen, som ikke burde kaldes.
Men mens Xavier Leroy fra OCaml havde affundet sig med, at problemet nok skyldtes den ene Skylake-maskine hos brugeren, der havde henvendt sig, så oplevede Ahref problemerne på alle deres Skylake-baserede maskiner. Det mindskede sandsynligheden for, at det blot havde været en fejl i produktionen af nogle enkelte chips.
Ahref henvendte sig til Intels kundesupport, og i april 2017 frigav Intel en opdateret version af errata til Skylake og Kaby Lake. Linux-distributionen Debian frigav kort efter en opdatering af Debians microcode til Skylake, hvori det blev beskrevet, at der kunne opstå en sjælden fejl.
Fejlen opstår, når GCC-compileren blander to registre, som hver fylder henholdsvis 1 og 4 bytes. GCC kan blande de to for at optimere koden, og hvis det sker i en tilstrækkeligt lille løkke, så kan det udløse hardwarefejlen på Skylake-processorerne.
Men for at nå til den konklusion skulle flere udviklere altså udelukke den mest sandsynlige forklaring: At de selv havde lavet en fejl i deres kode.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
