Mozilla kondigt nieuwe C/C++-debugger met 'opnamefunctie' aan

Mozilla heeft onder de naam Rr een debugger uitgebracht die het mogelijk maakt om draaiende programmacode 'op te nemen' om deze vervolgens stap voor stap af te spelen. Volgens Mozilla maakt Rr het debugproces minder vervelend en kunnen er meer bugs mee gevonden worden.

De Rr-debugger is door Mozilla-ontwikkelaars geschreven als hulpje bij het debuggen van Firefox-code die is geschreven in C en C++. Rr maakt tijdens het starten van de code een opname, waarbij onder andere geheugentransacties en breakpoints meegenomen worden. De 'opnames' kunnen vervolgens afgespeeld worden, waarbij net als een videorecorder stap voor stap vooruit en achteruit kan worden 'gespoeld'.

Volgens Mozilla maakt Rr het debuggen van code samen met GNU gdb een minder vervelende klus. Bovendien zou Rr, waarbij code op een deterministische wijze wordt gedebugd, het vinden van moeilijk te reproduceren bugs kunnen vergemakkelijken. Bij het maken van opnames en het afspelen met de Rr-debugger vertraagt de software wel; bij Firefox meldt Mozilla vertragingen tot driemaal de normale executiesnelheid en een gemiddelde vertraging met een factor 1,2.

Mozilla denkt dat Rr nuttig kan zijn voor andere programmeurs die met C++- en C-code werken en heeft de debugger onder een MIT-licentie op GitHub geplaatst. Toch zijn er de nodige beperkingen aan de tool. Zo werkt deze momenteel voor single threaded 32bit-code op x86-processors samen met het Linux-besturingssysteem. Of er een port komt naar bijvoorbeeld Windows is de vraag, omdat dit veel extra werk zou kosten. Wel zou een x64-versie voor Linux worden overwogen. Een andere beperking is dat de tool niet geschikt is voor ARM-socs omdat deze architectuur de benodigde performance counter features niet zou bieden.

Reacties (24)

Hoe werken deze stappen precies? Worden alle geheugen veranderingen meegenomen en zijn deze in tijdsvolgorde afspeelbaar?

Dit zou een welkome toevoeging zijn in het dagelijkse debug-werk. Alleen gaat dit natuurlijk bakken met RAM kosten, zeker als je meerdere stappen gaat bewaren. Hopelijk wordt in de toekomst multithreading en Windows ondersteuning nog toegevoegd, dan wordt het echt interessant.

Het is eigeniljk heel eenvoudig. Programmaverloop wordt als een deterministisch proces behandeld. Invloeden 'van buitenaf' die de uitvoer van een programma beinvloeden worden opgenomen, en bij een 'replay' opnieuw afgespeeld. Hierdoor houdt je geen niet-deterministische vectoren meer over, waardoor je gehele programma feilloos naar een bepaald 'punt' in de uitvoer te sturen is.

Een voorbeeld van acties die moeten worden opgenomen zijn dingen als het gebruik van 'gettime()' achtige functies. Het antwoord van deze functie is variabel, gebaseerd op het moment waarop je deze functie called. Bij een replay wil je dus het 'statische', opgenomen antwoord krijgen.

Deze opnametechniek is niet de enige methode die gebruikt wordt. Een andere, volledige techniek is bijvoorbeeld het onthouden van alle datawijzigingen. Effectief maak je alle data hiermee immutable, en onthoudt je oude references. Een voorbeeld:
int x = 1 // X maak je aan, met waarde 11
x += 10 // De originele X blijft bestaan, een nieuwe wordt 11. Deze nieuwe X verwijst onder de moterkap vaak ook gelijk naar de oude, waardoor je over een tijdsspanne een soort ketting aan oude states krijgt. Deze ketting kan je weer gebruiken om historische state te reconstrueren. Nadeel van deze aanpak is dat je veel meer geheugen nodig hebt, met als voordeel dat je geen 'replays' hoeft te doen van je code.

Voor wat algemene omniscient debugging gerelateerde projecten kan ik ook naar deze twee links verwijzen:
http://www.lambdacs.com/debugger/debugger.html
http://homes.cs.washingto...s/timelapse/research.html

Edit @ hieronder: Ze voeren alle code momenteel single threaded uit, juist om de onderstaande problemen voorlopig even te negeren en de rest van het probleem behapbaar te maken. Het is inderdaad een erg lastig (en gedeeltelijk nog open) probleem.

Edit 2: Nee, zie hierboven. Die library zit wel dicht bij een andere oplossing, namelijk het 'afspelen' van je niet-deterministische functies. Er wordt met een LD_PRELOAD een soort wrapper library ingeladen, welke bij record gedrag gettime() als het ware proxy'd. Het antwoord slaat hij op. Bij een replay zal de 'proxy' het vorige antwoord uitlezen en teruggeven aan de applicatie.

[Reactie gewijzigd door icyx op 27 maart 2014 15:34]

Ik vraag me alleen af of (en hoe) ze ook alle thread context switches opslaan, om zo multithreaded code deterministisch te maken...

Moet je je applicatie soms linken tegen een alternatieve thread library?

[Reactie gewijzigd door Anoniem: 415197 op 27 maart 2014 15:28]

... Zo werkt deze momenteel voor single threaded 32bit-code ...

Niet, blijkbaar...

De meest ingewikkelde code is juist multi-threaded. Single-threaded code kun je meestal gewoon met wat print-statements ook wel debuggen.

Een stap in de goede richting is het wel.

Verder kan ik "valgrind" enorm aanraden als debug-hulpmiddel voor C++ programma's.

[Reactie gewijzigd door Anoniem: 415197 op 27 maart 2014 16:08]

Een "Step back" functie is inderdaad de functie die ik het meeste mis tijdens debuggen.

gdb kan dat sinds versie 7 http://www.sourceware.org/gdb/news/reversible.html (op sommige platforms)

Sweet, dat scheelt een hoop breakpoints aanmaken en opnieuw runnen .

TotalView van RogueWave kan dit al jaren en is enorm nuttig.

Wie kan me dit even uitleggen.
Draaiende code opnemen en later debuggen. Dat kan je toch zelf ook al met een debugger?
Daar heb je niet een opname voor nodig lijkt me. Ik zie het nut hier nog niet zo van in.
Zelf gebruik ik VBA om dat later om te zetten naar een andere taal als ik een Office Pakket wil benaderen. Maar dat is niet hetzelfde.

Een normale debugger gaat alleen vooruit in de tijd; kunnen terugspoelen is echt een mega toffe en handige feature die ik buiten C/C++ ook wel zou willen hebben om eerlijk te zijn.

simpelste voorbeeld.

ergens in de code zit er een fout, en je kent wel de handeling , maar weet niet precies waar deze optreed.

Met een normale debugger start je een sessie, en ga je stap per stap verder tot je de code vind.
Spreekt voor zich dat dit een hele tijd kan duren.

Als je echter kan terug spoelen, dan voer je gewoon alle stappen uit in run mode, halt het programma aan de error en dan keer je stap per stap terug om te zien hoe het programma daar kwam (vooral handig bij algemene error afhandeling )

dank je, wordt een heel stuk duidelijker voor me na deze uitleg.
Wel een uitermate handige functie. Soms zit ik zo lang te debuggen (for loops) dat je er soms voorbij schiet. Dan is dit wel reuze welkom.

In C# kan het al in Visual Studio, volgens mij kun je de pointer zelfs binnen een if statement slepen die je normaal niet haalt.

Als je zèlf het programma uitvoert en de fout kan simuleren ja. Dit systeem laat blijkbaar toe dat als een gebruiker een fout krijgt, er een logfile wordt gemaakt die de ontwikkelaar kan "afspelen".

http://chrononsystems.com/

Is er dus al een tijdje voor Java apps, werkt zelfs voor multithreaded apps, als er iets is wat zeker voor java spreekt is het wel de kwaliteitsvolle tooling/omgevingen errond.

Dat ziet er veelbelovend uit, bedankt!

Zie ook http://msdn.microsoft.com/en-us/library/dd264915.aspx voor de intellitrace functie die in Visual Studio zit.

Dat is niet supported voor Native code.

Ik weet niet hoe Rr precies werkt, maar het is waarschijnlijk vergelijkbaar met Chronon, een "DVD-recorder" voor Java.
Zie dit filmpje voor een idee wat er allemaal mogelijk is. In bepaalde gevallen kan dit zeker een meerwaarde hebben buiten een 'gewone' debugger.

Het probleem met een traditionele debugger is soms dat je stap voor stap door de code heen gaat. Dat kan betekenen dat het programma tijdens de debug sessie zich anders gedraagt dan tijdens real-time. (b.v. communicatie software) Als ik een stukje draaiende code kan opnemen, en later op mijn gemak kan debuggen, heb ik extra mogelijkheden.

Ben benieuwd hoe er om wordt gegaan met dingen die niet terug te draaien zijn, zoals bijvoorbeeld I/O.

Blijkbaar logt 'ie alle in-en output om deze later opnieuw af te spelen.

dit lijkt me gewoon geweldig
zou er ooit zo iets voor javascript komen? (of misschien er al zijn?)