Debugging 2013- Michael Rasmussen

IndledningDynamisk analyseAddressSanitizerThreadSanitizer

Praktisk brugKonklusion

Mere information

Dynamiske analysatorer til C/C++

Michael Rasmussen

26. oktober 2013

Michael Rasmussen Dynamiske analysatorer til C/C++



Mere information

Indholdsfortegnelse

Indledning

Dynamisk analyse

AddressSanitizer

ThreadSanitizer

Praktisk brug

Konklusion

Mere information




Mere information

Mal

I Malet er 100% korrekt programmel - lettere sagt end gjort

I Kan ikke generelt bevise korrekthed

I Inputdomænet er ofte meget stort, ikke alle input er ligevigtige/sandsynlige

I Nogle output er meget uacceptable (hvis de f.eks. giver enangriber mulighed for at afvikle arbitrær kode pa ens server)

I Sæt ind, hvor det giver mest mening




Mere information

Fejlklasser

I ProgrammeringsfejlI LogikfejlI Forkert brug af API

I Udefineret opførselI HukommelsesfejlI Uinitialiserede variableI HeltalsoverløbI Samitidighedsproblemer

I Hukommelseslæk

I o.s.v.




Mere information

Metoder til automatisk fejlsøgning/tilsikring afprogramkorrekthed

I Statiske analyse

I Lad oversætteren hjælpe! Oversæt altid med -Wall -Wextra (ellertilsvarende)!

I Unit-, system-, stress- og regressionsafprøvninger

I assert, køretidskontrol af invarianter (eksempelvis afiteratorgyldighed)

I Dynamisk analyse




Mere information

I Ingen ”silver bullet”

I En kombination af teknikker er nødvendig

I Helst ikke for omkostningsfuldt (i arbejds- og køretid)

I Kan vi ikke fa hjælp?




Mere information

Hvad er dynamisk analyse?

I Programafviklingen inspiceres under køretid for forskelligefejlsituationer og mistænkelig opførsel

I Normalt automatisk uden ekstra programmørarbejde

I Giver øjeblikkelig feedback - tættere pa fejlkilden (som oftest)

I Virker ved at programmet afvikles i en virtuel maskine, kendtefunktioner opsnappes eller programkoden udvides automatiskmed ekstra køretidscheck




Mere information

Ulemper

I Kun afviklet kode + input kontrolleres

I Programafvikling bliver normalt markant langsommere

I Programmet afvikles ikke under ”rigtige”forhold (debug build,ændret timing, o.s.v.)

I Falske negativer/positiver (programforhold kan maskererigtige fejl, korrekt programmel kan give udslag)

I Kan ofte ikke kombineres, anden debugging kan blivebesværliggjort

I Beviser ikke fravær af fejl




Mere information

Eksempler pa dynamiske analysatorer

I Valgrind (http://valgrind.org/)

I CodeGuard (Embarcadero RadStudio/C++Builder)

I BoundsChecker (Borland/Microfocus BoundsChecker)

I Purify (IBM Rational Purify)

I *sanitizer Clang 3.2/GCC 4.8


http://valgrind.org/

http://www.embarcadero.com/

http://www.borland.com/products/devpartner/try/devpartnervisualcboundscheckersuite.aspx

http://www-03.ibm.com/software/products/us/en/rational-purify-family



Mere information

Instrumenterede dynamiske analysatorer

I Programkoden udvides af oversætteren til at indeholde diversecheck

I Har potentielt mere information end en stand-alone analysator

I Kan anskues som automatisk tilføjede asserts




Mere information

Hvad er AddressSanitizer?

I Alle hukommelsestilgange instrumenteres af oversætteren

*address = ...; // or: ... = *address;

// Omskrives til

if (IsPoisoned(address)) {

ReportError(address , kAccessSize , kIsWrite);

}

*address = ...; // or: ... = *address;

I Afdækker flere klasser af hukommelsesfejlI Over- og underløbI Brug af dynamisk allokeret hukommelse efter frigivelseI Tilgang til ugyldige hukommelsesomrader (findes sædvaneligvis

ogsa ved normal afvikling)I Desværre ikke alle hukommelsesfejl (off-by-one fejl findes let,

off-by-4K er straks sværere)




Mere information

Demo 1

// 01.cpp

#include <string.h>

int main() {

char x[8];

strcpy(x, "01234567");

}

$ g++-4.8 -Wall -Wextra -std=c++11 -g 01.cpp

$ ./a.out

$ valgrind ./a.out

<<<< klip >>>>

==4587== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)




Mere information

Demo 1 (fortsat)

$ g++-4.8 -Wall -Wextra -std=c++11 -g -fsanitize=address 01.cpp

$ ./a.out

=================================================================

==4601== ERROR: AddressSanitizer: stack -buffer -overflow on address

0x7fff8e4c6b58 at pc 0x40099d bp 0x7fff8e4c6b20 sp 0x7fff8e4c6b18

WRITE of size 1 at 0x7fff8e4c6b58 thread T0

#0 0x40099c (/home/mras/Dropbox/Pres/asan /01/a.out+0 x40099c)

#1 0x7fb64b80ede4 (/lib/x86_64 -linux -gnu/libc -2.17. so+0 x21de4)

#2 0x4007b8 (/home/mras/Dropbox/Pres/asan /01/a.out+0 x4007b8)

Address 0x7fff8e4c6b58 is located at offset 40 in frame <main > of T0’s stack:

This frame has 1 object(s):

[32, 40) ’x’

<<<< klip >>>>




Mere information

Demo 2

// 02.cpp

char g[8];

int main() {

return g[8];

}

$ g++-4.8 -Wall -Wextra -std=c++11 -g -fsanitize=address 02.cpp

$ ./a.out

==4637== ERROR: AddressSanitizer: global -buffer -overflow on address

0x0000006010e8 at pc 0x4007e6 bp 0x7fff13416e10 sp 0x7fff13416e08

READ of size 1 at 0x0000006010e8 thread T0

#0 0x4007e5 (/home/mras/Dropbox/Pres/asan /02/a.out+0 x4007e5)

#1 0x7f04d84fbde4 (/lib/x86_64 -linux -gnu/libc -2.17. so+0 x21de4)

#2 0x4006e8 (/home/mras/Dropbox/Pres/asan /02/a.out+0 x4006e8)

0x0000006010e8 is located 0 bytes to the right of global variable ’g (02. cpp)’

(0 x6010e0) of size 8

’g (02. cpp)’ is ascii string ’’




Mere information

Hvad er ThreadSanitizer?

I Værktøj til at pavise datakapløb i programmet

I Hukommelsestilgange (der ikke er beviseligt kapløbsfri) iprogrammet instrumenteres og sendes til en tilstandsmaskine

I Tilstandsmaskinen gemmer en begrænset liste afhukommelsestilgange og sammenholder dem for at afdækkedatakapløb

I Fejl kan slippe igennem, men fundne problemer har højsandsynlighed for at være reelle

I Kender til atomiske variable og efterhanden det meste afC++11 standardbiblioteket




Mere information

Demo

// 01.cpp

#include <pthread.h>

int g;

void* f(void*) {

g++;

return NULL;

}

int main() {

pthread_t t1, t2;

pthread_create (&t1, NULL , f, NULL);

pthread_create (&t2, NULL , f, NULL);

pthread_join(t1, NULL);

pthread_join(t2, NULL);

return g;

}




Mere information

Demo (fortsat)

$ g++-4.8 -Wall -Wextra -std=c++11 -g -fsanitize=thread -pie -fPIC 01.cpp \

-Wl,--no-as -needed -ltsan -pthread -lpthread && ./a.out

WARNING: ThreadSanitizer: data race (pid =14413)

Read of size 4 at 0x7ff7cd0e609c by thread T2:

#0 f(void*) /home/mras/Dropbox/Pres/tsan /01/01. cpp:6 (exe+0 x000000000b8d)

#1 __tsan_write_range ??:0 (libtsan.so.0+0 x00000001b1c9)

Previous write of size 4 at 0x7ff7cd0e609c by thread T1:

#0 f(void*) /home/mras/Dropbox/Pres/tsan /01/01. cpp:6 (exe+0 x000000000ba8)

#1 __tsan_write_range ??:0 (libtsan.so.0+0 x00000001b1c9)

Thread T2 (tid =14415 , running) created by main thread at:

#0 pthread_create ??:0 (libtsan.so.0+0 x00000001eccb)

#1 main /home/mras/Dropbox/Pres/tsan /01/01. cpp:13 (exe+0 x000000000c13)

Thread T1 (tid =14414 , running) created by main thread at:

#0 pthread_create ??:0 (libtsan.so.0+0 x00000001eccb)

#1 main /home/mras/Dropbox/Pres/tsan /01/01. cpp:12 (exe+0 x000000000bf6)

SUMMARY: ThreadSanitizer: data race /home/mras/Dropbox/Pres/tsan /01/01. cpp:6 f(

void*)




Mere information

Demo (fortsat)

Retfærdigvis skal det nævnes at helgrind ogsa finder datakapløbet:

$ g++-4.8 -Wall -Wextra -std=c++11 -g 01.cpp -Wl,--no-as-needed \

-pthread -lpthread && valgrind --tool=helgrind ./a.out

<<<< klip >>>>

==14397== Possible data race during read of size 4 at 0x60105C by thread #3

==14397== Locks held: none

==14397== at 0x400785: f(void*) (01. cpp:6)

==14397== by 0x4C2EA06: ??? (in /usr/lib/valgrind/vgpreload_helgrind -amd64 -

linux.so)

==14397== by 0x4E3DF6D: start_thread (pthread_create.c:311)

==14397== by 0x596B9CC: clone (clone.S:113)

==14397==

==14397== This conflicts with a previous write of size 4 by thread #2

==14397== Locks held: none

==14397== at 0x40078E: f(void*) (01. cpp:6)

==14397== by 0x4C2EA06: ??? (in /usr/lib/valgrind/vgpreload_helgrind -amd64 -

linux.so)

==14397== by 0x4E3DF6D: start_thread (pthread_create.c:311)

==14397== by 0x596B9CC: clone (clone.S:113)

<<<< klip >>>>




Mere information

Andre sanitizers

I MemorySanitizer - Læsning af uintialiseret hukommelse

I IntegerSanitizer - Heltalsoverløb

I UndefinedSanitizer - Finder udefineret opførsel, der er”billig”at have køretidscheck for

I Flere pa vej




Mere information

Omkostninger

I Falsk tryghedsfølelse - et fravær af konstaterede fejl betyderikke at programmet er korrekt eller fejlfrit

I Forøget køretid og hukommelsesforbrug (bade rigtig og virtuelhukommelse)

I Ændring af timing

I Kan ikke bruges sammen - afprøvning med bade Thread- ogAddressSanitizer nødvendig

I Falske positiver

I Kun afprøvet kode/input checkes




Mere information

Hvordan kommer man i gang?

I Alle unittests og særlige stresstests kører under Thread- ogAddressSanitizer (gerne altid)

I Gør et hjørne af koden klar - brug evt. supressions

I Na til et punkt, hvor alle detekterede problemer er værd atundersøge

I Husk: Overvej en ekstra gang om koden er korrekt inden enpotentiel falsk positiv afvises




Mere information

Konklusion

I Sanitizers kan hjælpe til at automatisk at afdække flereklasser af fejl

I Garanterer ikke korrekthed, men giver en bedre”mavefornemmelse”

I Det bør være et mal at ens program er ”clean”under afviklingi valgrind og med Thread- og AddressSanitizer

I Bør bruges i kombination med andre teknikker (herunderstatisk programanalyse)

I Det betaler sig, at finde fejl tidligt (ment bade som tæt pa atfejlen blev introduceret og tæt pa fejlkilden i programkoden)




Mere information

Hægter

I https://code.google.com/p/address-sanitizer/

I http://clang.llvm.org/docs/AddressSanitizer.html

I https://code.google.com/p/thread-sanitizer/

I http://clang.llvm.org/docs/ThreadSanitizer.html


https://code.google.com/p/address-sanitizer/

http://clang.llvm.org/docs/AddressSanitizer.html

https://code.google.com/p/thread-sanitizer/

http://clang.llvm.org/docs/ThreadSanitizer.html

Date post:	05-Dec-2014
Category:	Technology
Upload:	mediehuset-ingenioren-live
View:	167 times
Download:	0 times

Debugging 2013- Michael Rasmussen

Technology