Iedereen die wel eens geprogrammeerd heeft, houdt van de momenten waarin hij creatief kan zijn en alles kan maken wat hij maar wil. Maar ook iedereen die wel eens geprogrammeerd heeft, heeft een hekel aan die momenten waarin een enkele bug alles dwarszit, die maar niet gevonden kan worden. Dit heeft vaak uren turen naar je code tot gevolg, en nog eens uren internet afstruinen naar de oplossing.
Een paar slimme koppen van MIT hebben dit proces echter geautomatiseerd. Ze hebben in hun project Codephage een tool ontwikkeld, die zelf het foute programma vergelijkt met een soortgelijk programma waarin dit wel werkt, dit analyseert, en een oplossing aandraagt die de bug zou moeten oplossen. Toekomstmuziek? Oordeel zelf!
Bronnen:
Kort artikel over Codephage op Bits & Chips.
Demo en uitleg van auteurs.
Laatste berichten
-
16:45
wig 8
-
15:56
Programmeren met vectoren 6
-
14:53
Straatklok loopt 5 minuten voor 12
-
23:12
speciale rel. theorie 10
-
22:36
Gravity and gravitation 4
-
22:24
[scheikunde] vraag Chemie - wat is de oplossing? 10
-
19:47
Bruine vlekken op treinaanwijzerbord 10
-
19:44
Vogels in de stad zijn goede klussers 2
-
19:12
Rood laserlicht 3
-
17:30
Herleiden afmetingen vanaf een foto 21
-
25 apr
[wiskunde] Prijs Product per KG; Alternatief Inzicht 3
-
25 apr
do-re-mi-fa-so vliegtuigen 9
-
25 apr
geen minkowski-ruimte toch? Doe ik dit nou fout? 17
-
25 apr
[natuurkunde] kroon van koning op Syracuse 10
-
25 apr
2013 – Augustus Vraag 3 3
-
24 apr
Vraag 2009 Juli Vraag 5 5
-
24 apr
positie 2
-
24 apr
Schroefdraad berekening 8
-
24 apr
[scheikunde] Kan chloorgas de geleiding van elektriciteit belemmeren? 9
-
23 apr
Weerfrustratie 9
Nieuwsberichten
-
04 mar
Een nieuw soort magnetisme: altermagnetisme
-
31 okt
AI kan via stem diabetes vaststellen 11
-
21 okt
Einstein krijgt wéér gelijk 45
-
07 feb
witter dan wit 20
-
19 jun
irrigatie en de aardas
MIT fixt bugs door oplossing af te kijken
Moderator: Astro
-
- Berichten: 52
Re: MIT fixt bugs door oplossing af te kijken
De bug die het artikel beschrijft geeft een unhandled exception bij bepaalde invoer, waardoor het programma crasht. De "codephage" software gaat dan op zoek naar een programma wat hetzelfde doet, met handled exception, dus waar de invoer-fout WEL wordt afgehandeld. Dus de de melding wel laat zien aan de gebruiker en niet crasht. Leuk.
Maar.. hier wordt het m.i. ongeloofwaardig,
"Vervolgens wordt in het ontvanger-programma gezocht naar variabelennamen voor de relevante bytes in het donorprogramma. De symbolische expressie wordt hiermee volautomatisch omgezet in een patch en op de juiste plek toegevoegd."
Met de zoekerij naar een "match" in het eerste gedeelte, kun je zo'n match misschien vinden, maar stel dat de match werkt in het andere programma (hoe test men dat ?), kun je een invoeg-punt vinden voor de Handled exception in de binary ?? (op byte niveau), je weet niet, of het andere programma bijv. nog iets extra's doet, of iets wat niet de bedoeling is. Je weet ook niet, of de melding van toepassing is in jouw programma. Het lijkt me eerlijk gezegd nogal ingewikkeld, om een dergelijke beoordeling en beslissing te programmeren. Ook, omdat de tekst van de melding kan verwijzen naar een vertaaltabel (die je niet hebt), of (erger) in het Portugees of Frans is gesteld.
Misschien is de toepassing eenvoudiger, als je weet wat je doet.
De codephage methode lijkt me dus wel handig, als je veel versies van hetzelfde programma hebt en je doet het op broncode niveau en niet in de binary. Maar goed.. op zoiets blind varen lijkt me sowieso onmogelijk.`
Ook is het de vraag, of programmeurs de binaire oplossing (patch) accepteren. Het maakt je als programmeur wat onzeker, wanneer er halverwege je project "ergens" patches moeten worden ingevoegd in je applicatie, waarvan je niet weet, wat die precies doen. Het vereist m.i. gedetalilleerde kennis van codephage zelf, om er goed mee te kunnen werken !
Lx (software ontwikkelaar)
Maar.. hier wordt het m.i. ongeloofwaardig,
"Vervolgens wordt in het ontvanger-programma gezocht naar variabelennamen voor de relevante bytes in het donorprogramma. De symbolische expressie wordt hiermee volautomatisch omgezet in een patch en op de juiste plek toegevoegd."
Met de zoekerij naar een "match" in het eerste gedeelte, kun je zo'n match misschien vinden, maar stel dat de match werkt in het andere programma (hoe test men dat ?), kun je een invoeg-punt vinden voor de Handled exception in de binary ?? (op byte niveau), je weet niet, of het andere programma bijv. nog iets extra's doet, of iets wat niet de bedoeling is. Je weet ook niet, of de melding van toepassing is in jouw programma. Het lijkt me eerlijk gezegd nogal ingewikkeld, om een dergelijke beoordeling en beslissing te programmeren. Ook, omdat de tekst van de melding kan verwijzen naar een vertaaltabel (die je niet hebt), of (erger) in het Portugees of Frans is gesteld.
Misschien is de toepassing eenvoudiger, als je weet wat je doet.
De codephage methode lijkt me dus wel handig, als je veel versies van hetzelfde programma hebt en je doet het op broncode niveau en niet in de binary. Maar goed.. op zoiets blind varen lijkt me sowieso onmogelijk.`
Ook is het de vraag, of programmeurs de binaire oplossing (patch) accepteren. Het maakt je als programmeur wat onzeker, wanneer er halverwege je project "ergens" patches moeten worden ingevoegd in je applicatie, waarvan je niet weet, wat die precies doen. Het vereist m.i. gedetalilleerde kennis van codephage zelf, om er goed mee te kunnen werken !
Lx (software ontwikkelaar)
-
- Moderator
- Berichten: 4.097
Re: MIT fixt bugs door oplossing af te kijken
Toch is dat volgens mij wel wat ze doen. De PDF gaat vrij uitgebreid in op hoe ze ten eerste kijken welke bytes ervoor zorgen dat het programma een error geeft, en vervolgens welke source code daarbij hoort. Het doel van de eerste is juist om een applicatie-onafhankelijke check te genereren (slides 17-25). In slides 26-34 wordt (zeer beknopt) uitgelegd hoe ze van byte code naar source code vertalen. Slide 30 geeft hierbij het stappenplan. De ontwikkelaar accepteert (of weigert) uiteindelijk dus niet de binaire patch, maar de source code patch. Ik zou er voorlopig ook nog niet blind op willen varen, maar het kan wel helpen om bijvoorbeeld een off-by-one error op te sporen. Indien het programma de juiste patch aandraagt, zie je het zelf ook al snel.
Het verifiëren of de patch werkt, wordt gedaan aan de hand van test scripts. In het geval van overflow errors (zoals in het meest gebruikte voorbeeld), zoeken ze met een bepaalde methode (tool: DIODE) naar een input die voldoet aan de eisen en die een een integer overflow tot gevolg heeft. Indien deze niet gevonden wordt, is de bug gefixt.
Het tweede gedeelte van de PDF (vanaf slide 56) gaat echter over een andere techniek van automatisch patchen, helemaal gericht op test cases, genaamd RC2. Deze heb ik niet helemaal doorgenomen. Wat grappig is: in slide 74 wordt hier nog gewezen op een pitfall van het testen met test scripts: indien je bijvoorbeeld in je code een if statement hebt om slechte input te weigeren, en je hebt wel een test case die checkt op slechte input, maar geen test case die checkt op goede input, dan wordt de oorspronkelijke if statement simpelweg verwijderd.
Het verifiëren of de patch werkt, wordt gedaan aan de hand van test scripts. In het geval van overflow errors (zoals in het meest gebruikte voorbeeld), zoeken ze met een bepaalde methode (tool: DIODE) naar een input die voldoet aan de eisen en die een een integer overflow tot gevolg heeft. Indien deze niet gevonden wordt, is de bug gefixt.
Het tweede gedeelte van de PDF (vanaf slide 56) gaat echter over een andere techniek van automatisch patchen, helemaal gericht op test cases, genaamd RC2. Deze heb ik niet helemaal doorgenomen. Wat grappig is: in slide 74 wordt hier nog gewezen op een pitfall van het testen met test scripts: indien je bijvoorbeeld in je code een if statement hebt om slechte input te weigeren, en je hebt wel een test case die checkt op slechte input, maar geen test case die checkt op goede input, dan wordt de oorspronkelijke if statement simpelweg verwijderd.
