dinsdag 16 oktober 2007

Adv. debugging: Stack dumps met Process Explorer

In een eerder artikel heb ik uitgelegd hoe je zelf een stack dump kunt maken. Dit vooral bruikbaar bij exceptions, en soms ook voor het debuggen van een bepaalde situatie (”hoe komt hij hier?”).
Maar hoe kun je de stack bekijken als je programma vastloopt? In Delphi kun je het programma pauzeren en de stack bekijken, maar wat als het net buiten Delphi of op een (andere) server draait?

Process Explorer biedt dan uitkomst. Zoals ik al zei in een eerder artikel over Process Explorer: het is een super programma waar ik niet zonder kan. Je kunt er namelijk ook de stack mee bekijken van elke thread van een willekeurig programma. Dubbelklik hiervoor op een programma in de tree van Process Explorer en selecteer de “Threads” tab:

Dubbelklik vervolgens op een thread (hierboven is maar 1 thread) of klik op de “Stack” knop:

Het probleem is echter dat je dan geen beschrijvende namen ziet: alleen bijvoorbeeld een offset van 0×60664 bytes.

De truc hiervoor is om eerst een .map file te maken, en deze naar een .dbg file om te zetten:
Delphi -> Project Options -> Linker -> Map file -> Detailed
(zet ook eerst “optimization” UIT en “Stack frames” AAN op de compiler tab). Druk op “build” om opnieuw het programma te builden en om een map file te krijgen. Vervolgens moet van deze Delphi .map file omgezet worden naar een Windows debug file (.dbg).
Gebruik hiervoor “map2dbg”:
http://www.wischik.com/lu/programmer/ms-dbg.zip
Dit klein programmaatje moet via de command line (bijv. batch bestand) uitgevoerd worden:
map2dbg.exe .
Het bewuste programma wordt dan intern gemarkeerd dat het Windows Debug informatie bevat, en wordt omgezet naar .

Daarna moet in Process Explorer de directory als “symbol path” opgeven waar de bewuste .dbg file staat:
Options -> Configure Symbols

Als je dan een stack dump opvraagt, krijg je wel de volledige namen te zien:

Opmerking: map2dbg lijkt niet (altijd) te werken met Delphi 2007.
Bovenstaande demo lukte met 2007 niet en met Delphi 7 wel…

Soms heb je een nieuwe versie van “dbghelp.dll” en “imagehlp.dll” nodig:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.5.3.8.exe

“Now” functie is niet betrouwbaar! (ivm zomer/winter tijd)

In Delphi geeft de functie “Now” de lokale tijd terug. Dit is dus de gecorrigeerde tijd ten opzicht van de GMT of UTC tijd. Oftewel: de lokale tijd is de tijd rechtsonderin op de taakbalk.
Deze tijd is onderhevig aan zomer/winter tijd aanpassingen, wat al dan niet automatisch door Windows wordt aangepast…

Deze functie is dus niet betrouwbaar om de tijd te meten tussen 2 tijdstippen:
je hebt nl een kleine kans (van 2x 1 uur per jaar) dat de tijd 1 uur vooruit of achteruit verspringt ivm zomer/winter tijd. Vooral als kritische onderdelen van je programma hiervan gebruik maakt, is dit belangrijk om te weten!

Oplossing hiervoor is om gebruik te maken van de “GetSystemTime” API van Windows, en niet de “GetLocalTime” die voor “Now” gebruikt wordt.
Ik heb hiervoor een “NowUTC” functie gemaakt:

function NowUTC: TDatetime;
var
SystemTime: TSystemTime;
begin
GetSystemTime(SystemTime);
Result := SystemTimeToDateTime(SystemTime);
end;

Voor wat extra achtergrond informatie:

  • Windows slaat zowieso intern alle tijden als “local” time op. Dus bestanden, logs, etc. Tijdens zomer/winter tijd wissel kan het dus voorkomen dat een bestand opeens 1 uur te oud of zelfs 1 uur te jong (in de toekomst) is! Zie KB van Microsoft:
    “Time stamp changes with daylight savings”

    http://support.microsoft.com/kb/q129574/
  • De “SetLocalTime” API moet je 2x aanroepen om de PC tijd goed aan te passen. De eerste keer wordt nl de tijd eerst gecorrigeerd ten aanzien van de huidige tijd (dus 1 uur erop/eraf als je meer dan een half jaar veranderd) en kan dus 1 uur afwijken. De tweede keer zit je wel in goede winter/zomer tijd zone, en wordt de tijd wel goed gezet.
    Zie KB van Microsoft:
    “SetLocalTime/GetLocalTime Not the Same if Adjusting for Daylight Saving Time”
    http://support.microsoft.com/kb/q234735/
  • Leuk om te melden :-) dat Unix/Linux de tijd intern wel goed geregeld heeft:
    alles is intern GMT/UTC tijd, zodat het geen last heeft van de bovenstaande *kuch* features *kuch* van Windows. Zelfs Windows Vista heeft nog steeds de antieke en onbetrouwbare MS-DOS tijds bepaling! Meer informatie hierover:
    “IBM PC Real Time Clock should run in UT”
    http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

Instant Mantis: snel en direct een bug/issue tracking systeem opzetten

Een uitgebreid (!) verslag van een uit de hand gelopen experiment :-) voor het gebruiken van een issue tracking systeem.

Het bedrijf
Ik ben nu dik 2,5 jaar bij hetzelfde bedrijf gedetacheerd, en in die tijd is het bedrijf (ondanks of dankzij :-) ) flink gegroeid. Momenteel zitten we met 50 man in het nieuwe pand omdat het oude veel te klein werd. Niet alleen het bedrijf groeide, ook de projecten zelf groeiden (groter, ingewikkelder, etc).

Werkwijze
Wat niet direct mee groeide waren de werknemers zelf. Nog steeds wordt per project 1 status document in Word bijgehouden (groot, onoverzichtelijk, 1 persoon tegelijk wijzigen, etc). Nu worden daar voornamelijk mechanische dingen van de machines bijgehouden (aanpassingen), of klant/project gerelateerde zaken (wat besteld en geregeld moet worden). Want om alles van software bij te houden is een onbegonnen zaak.

Nu gaat dat meestal wel goed. De Voordelen van een klein bedrijf zijn de korte lijnen en de informele contacten. En de projecten waren nog te overzien. Er is een versie beheersysteem (Borland Starteam) en een eigen framework (met dank aan Aaldert :-) ). Bij problemen wordt de programmeur in kwestie aangesproken: “Als ik dit en dat doe, doet ie het niet meer” -> “Oké, ik zal even debuggen en een nieuwe versie maken”. Echter, niet iedereen houdt consequent een “changelog” bij van wat er bij welke versie veranderd is.

Huidig project
Momenteel werk ik aan een machine die nu bij 2 klanten staat: 4 in Duitsland en 2 in Engeland. En op de zaak zelf staat een proto type (voor testen). De laatste tijd hield ik de meeste dingen bij in de email: “Ik heb een probleem”, “Kun je dit en dat even voor me doen of maken?” -> “Stuur maar een email, anders vergeet ik het”. In Outlook gaf ik dan een vlag aan emails die ik af moest handelen. Dingen die mij te binnen schoten, schreef ik op een kladblok, of hield ik in een draft e-mail bij. Maar met 2 klanten die al met de machine werken (dankzij “Agile development” in plaats van de “Waterfall methode” :-) ) kreeg ik vaak de vraag (van projectleider) of iets al opgelost was, en zo ja in welke versie. Dankzij de changelog kon ik daar wel een antwoord opgeven, maar alleen ik had dus eigenlijk het overzicht.

Op zoek naar iets beters…
Natuurlijk wist ik wel dat het beter/anders kan en moest, maar je past je al gauw aan aan het bedrijf en komt in een bepaalde sleur vast te zitten (druk genoeg met programmeren, bug fixen, etc). Toen een nieuwe klant erbij kwam (in Nederland, met weer andere eisen & wensen) en de vakantie dichterbij kwam, werd het voor mij duidelijk: zo kan het niet meer, dit moet ik anders gaan doen. Ik ben toen op Internet wezen zoeken naar een bug/issue tracking systeem. Nu schrok ik een beetje van het aanbod: welke moest ik kiezen, en kon niet alles uitproberen (geen tijd). 1 naam kwam ik een aantal keren tegen, met goede recensies: Mantis. Op 1 site kreeg het zelfs een cijfer 9. Na wat zoeken op de site (http://www.mantisbt.org/) kwam ik “Instant Mantis” voor Windows tegen, wat precies voor mij geschikt was!

Instant Mantis
Mantis is een (open source) issue tracking systeem. Op site downloade ik gratis :-) de 20mb zip, wat na uitpakken 70mb groot bleek te zijn. In de hoofddirectory vond ik 2 batchbestanden: 1 om te starten en 1 op te stoppen. Zo simpel is het. Bij het starten wordt automatisch MySQL (database) en Apache (website) gestart. Default start Apache op poort 8008, maar dit kon in het batch bestand eenvoudig aangepast worden naar 80. Firefox opgestart en ik kon direct aan de slag. Alles kan/moet via de webpagina ingesteld en aangepast worden: projecten, users, issues, etc.

Bugs en todo’s worden als “issues” ingevoerd. Hierbij kunnen de standaard velden ingevoerd worden: priority, severity, description, notes, attachments, status, etc. Er kunnen ook eenvoudig “custom fields” aangemaakt worden, bijvoorbeeld een required “customer” veld met een lijst van klanten waarvoor een issue geldt. Gebruikers krijgen automatisch een e-mail bij een nieuwe issue, en de “poster” krijgt e-mails terug als de status veranderd (fixed,feedback), notitie is toegevoegd, etc.

Acceptatie
Eerst wilde ik gewoon voor mezelf gebruiken en uitproberen. Ik liet het even vallen bij een (assistent) projectleider bij de klant op locatie (heeft VPN verbinding naar de zaak zelf). Deze was meteen geïnteresseerd en heb hem toen de computernaam opgegeven waarop het draaide (vmware build server). Na 1 dag proberen was hij helemaal enthousiast en moest voor hem ook de andere machines bij die klant als projecten toevoegen, en de nodige users voor die projecten. Hij kan precies zien welke bugs en todo’s openstaan, krijg bericht als iets in een volgende versie gefixed is, etc. Alles kan nu precies gevolgd worden (evt discussies via notes, extra info via attachments, automatische changelog voor een versie etc. Na nu een week draaien willen hij en ik niet meer anders :-). Steeds meer mensen gaan het nu gebruiken, en zijn enthousiast. Er is vorige jaar iets vergelijkbaars geprobeerd met T-Plan, maar dit beviel erg slecht: traag via VPN, onoverzichtelijk en onduidelijke GUI (op een label klikken om editbox te krijgen…) en te beperkt.

Huidige status
Na de vakantie heeft Mantis zich steeds verder verspreidt over het bedrijf. Ondertussen is het duidelijk geworden dat dit officiëler gebruikt moet gaan worden. In plaats van dat het draait op een van de vmware build/release images, moet het natuurlijk op een “echte” interne server draaien, en ook voor buitenaf via de website bereikbaar zijn (in plaats van alleen via VPN).

Toekomst
Voorlopig zal Mantis nog wel gebruikt worden :-). Het biedt bovendien perspectieven voor de toekomst. Er zijn namelijk verscheidene 3rd party koppelmogelijkheden zoals test management en project en release management. Bijvoorbeeld de test scripts worden in het test management pakket ingevoerd, en als een test faalt of opmerkingen zijn, dan worden deze als issues in Mantis ingevoerd en gekoppeld.
Maar het is ook mogelijk dat eerst een uitgebreid onderzoek gedaan wordt naar andere mogelijkheden, omdat Mantis 1 van de vele pakketten is. Voorlopig voldoet het echter prima.

Discussie
Hebben anderen ook dergelijke ervaringen? En wat gebruiken jullie zelf? Hebben jullie nog aanbevelingen of tips?