În acest proiect veţi implementa un alocator simplu de memorie, similar sistemului malloc/free.

Responsabili:

• Darius Neațu (2017, 2016)
• Rareș Cheșeli (2017, 2016)

Autor inițial: Ștefan Bucur

Deadline hard: 18.12.2017

• 01.12.2017 - Am adaugat cateva clarificari in sectiunea Functionarea programului referitoare la variabile globale, instructiunea goto, functii permise etc.
• 02.12.2017 - Adăugarea unui schelet de cod în sectiunea Schelet .
• 02.12.2017 - Am adăugat sectiunea Q&A.
• 06.12.2017 - Am adăugat un warning mare (cu rosu) în secțiunea Testare. Acest update este pentru cei care nu au reușit să ruleze checkerul. NU s-a schimbat checkerul, dacă ați reușit să îl folosiți, atunci ignorați acest update. Dacă nu sunteți sigur că ați reușit să îl folosiți, recitiți secțunea menționată.
• 06.12.2017- Am adăugat în secțiunea Q&A întrebarea ”./reference ⇒ nu se poate rula”
• 14.12.2017- Am amânat deadline-ul. Deadline-ul final este pe 18 Decembrie. Decizie finală. ATENTIE! Este hard! Nu mai se accepta rezolvari dupa aceasta data.

În urma realizării acestui proiect, studentul va fi capabil:

• să lucreze cu pointeri pentru a manipula date stocate în memorie
• să lucreze cu mecanismul de alocare de memorie din biblioteca standard C
• să înţeleagă şi să implementeze conceptele din spatele unui alocator de memorie
• să lucreze cu funcţii de manipulare a şirurilor de caractere
• să înţeleagă şi să genereze hărţi de memorie

Așa cum ați aflat deja, locuitorii din satul lui Gigel sunt in război deschis cu barbarii. Aceștia din urmă sunt însă cei care, cu mulți ani înainte de trecerea la un stil de viață beligerant, erau recunoscuți pentru înclinația lor către știință. Aceea a fost perioada în care au scris biblioteca stdlib.

Odată cu începerea războiului, locuitorii din satul lui Gigel s-au văzut nevoiți să renunțe la folosirea acestei biblioteci. Totuși, pentru a putea efectua calculele necesare pentru viața de zi cu zi, ei sunt obligați de împrejurări să își scrie ei înșiși funcțiile de care au nevoie. Momentan, prioritatea o reprezintă funcțiile pentru alocarea dinamică a memoriei. Ajutați-i pe locuitorii din satul lui Gigel să implementeze funcțiile de care au nevoie.

Programul vostru va trebui să realizeze o simulare a unui sistem de alocare de memorie. Programul va primi la intrare comenzi de alocare, alterare, afişare şi eliberare de memorie, şi va trebui să furnizaţi la ieşire rezultatele fiecărei comenzi. Nu veţi înlocui sistemul standard malloc() şi free(), ci vă veţi baza pe el, alocând la început un bloc mare de memorie şi apoi presupunând că acela reprezintă toată “memoria” voastră, pe care trebuie s-o gestionaţi.

Un alocator de memorie poate fi descris, în termenii cei mai simpli, în felul următor:

• Primeşte un bloc mare, compact (fără “găuri”), de memorie, pe care trebuie să-l administreze. Acest bloc, în terminologia de specialitate, se numeşte arenă. De exemplu, sistemul de alocare cu malloc() are în gestiune heap-ul programului vostru, care este un segment special de memorie special rezervat pentru alocările dinamice.
• Utilizatorii cer din acest bloc, porţiuni mai mici, de dimensiuni specificate. Alocatorul trebuie să găsească în arenă o porţiune continuă liberă (nealocată), de dimensiune mai mare sau egală cu cea cerută de utilizator, pe care apoi o marchează ca ocupată şi întoarce utilizatorului adresa de început a zonei proaspăt marcată drept alocată. Alocatorul trebuie să aibă grijă ca blocurile alocate să nu se suprapună (să fie disjuncte), pentru că altfel datele modificate într-un bloc vor altera şi datele din celălalt bloc.
• Utilizatorii pot apoi să ceară alocatorului să elibereze o porţiune de memorie alocată în prealabil, pentru ca noul spaţiu liber să fie disponibil altor alocări.
• La orice moment de timp, arena arată ca o succesiune de blocuri libere sau ocupate, ca în figura de mai jos.

O problemă pe care o are orice alocator de memorie este cum este ţinută evidenţa blocurilor alocate, a porţiunilor libere şi a dimensiunilor acestora. Pentru această problemă există în general două soluţii:

• Definirea unor zone de memorie separate de arenă care să conţină liste de blocuri şi descrierea acestora. Astfel, arena va conţine doar datele utilizatorilor, iar secţiunea separată va fi folosită de alocator pentru a găsi blocuri libere şi a ţine evidenţa blocurilor alocate.
• Cealaltă soluţie, pe care voi o veţi implementa în această temă, foloseşte arena pentru a stoca informaţii despre blocurile alocate. Preţul plătit este faptul că arena nu va fi disponibilă în totalitate utilizatorilor, pentru că va conţine, pe lângă date, şi informaţiile de gestiune, însă avantajul este că nu are nevoie de memorie suplimentară şi este în general mai rapidă decât prima variantă.

Există mai multe metode prin care se poate ţine evidenţa blocurilor alocate în arenă, în funcţie de performanţele dorite. Voi va trebui să implementaţi un mecanim destul de simplu, care va fi prezentat în secţiunea următoare. Deşi nu este extrem de performant, se va descurca destul de bine pe dimensiuni moderate ale arenei (de ordinul MB).

În continuare vom considera arena ca pe o succesiune (vector) de N octeţi (tipul de date unsigned char). Fiecare octet poate fi accesat prin indexul său (de la 0 la N-1). Vom considera că un index este un întreg cu semn pe 32 de biţi (tipul de date int pe un sistem de operare pe 32 de biţi). De asemenea, va fi nevoie câteodată să considerăm 4 octeţi succesivi din arenă ca reprezentând valoarea unui index. În această situaţie, vom considera că acel index este reprezentat în format 'little-endian' (revedeţi exerciţiile de la laboratorul de pointeri pentru mai multe detalii şi citiţi acest articol mult mai descriptiv), şi astfel vom putea face cast de la un pointer de tip unsigned char * la unul de tip int*, pentru a accesa valoarea indexului, stocată în arenă.

Figura de mai jos ilustrează structura detaliată a arenei, în decursul execuţiei programului:

Se poate observa că fiecare bloc alocat de memorie (marcat cu un chenar îngroşat) constă din două secţiuni:

• Prima secţiune, de gestiune, este reprezentată de 12 octeţi (3 * sizeof(int)) împărţiţi în 3 întregi (a câte 4 octeţi fiecare). Cei trei întregi reprezintă următoarele:
  • Primul întreg reprezintă indexul de start al blocului următor de memorie din arenă (aflat imediat “la dreapta” blocului curent, dacă privim arena ca pe o succesiune de octeţi de la stanga la dreapta). Se consideră că un bloc începe cu secţiunea de gestiune, şi toţi indicii la blocuri vor fi trataţi ca atare. Dacă blocul este ultimul în arenă (cel mai “din dreapta”), atunci valoarea primului întreg din secţiune va fi 0.
  • Cel de-al doilea întreg din secţiune reprezintă indexul de start al blocului imediat anterior din arenă. Dacă blocul este primul în arenă, atunci valoarea acestui întreg va fi 0.
  • Cel de-al treilea întreg din secţiune reprezintă lungimea totală a blocului, adică lungimea celor două secţiuni la un loc (nu doar a datelor alocate utilizatorului).
• A doua secţiune conţine datele efective ale utilizatorului. Secţiunea are lungimea în octeţi egală cu dimensiunea datelor cerută de utilizator la apelul funcţiei de alocare. Indicele returnat de alocator la o nouă alocare reprezintă începutul acestei secţiuni din noul bloc, şi 'nu' începutul primei secţiuni, întrucât partea de gestiune a memoriei trebuie să fie complet transparentă pentru utilizator.

După cum se poate observa din figura de mai sus, la începutul arenei sunt rezervaţi 4 octeţi care reprezintă indicele de start - indicele primului bloc (cel mai “din stânga”) din arenă. Dacă arena nu conţine nici un bloc (de exemplu, imediat după iniţializare), acest indice este 0.

Indicele de start marchează începutul lanţului de blocuri din arenă: din acest indice putem ajunge la începutul primului bloc, apoi folosind secţiunea de gestiune a primului bloc putem găsi începutul celui de-al doilea bloc, şi asa mai departe, până când ajungem la blocul care are indexul blocului următor 0 (este ultimul bloc din arenă). În acest mod putem traversa toate blocurile din arenă, şi de asemenea să identificăm spaţiile libere din arenă, care reprezintă spaţiile dintre două blocuri succesive.

Este de remarcat faptul că lanţul poate fi parcurs în ambele sensuri: dintr-un bloc putem ajunge atât la vecinul din dreapta, cât şi la cel din stânga.

De asemenea, atunci când este alocat un bloc nou sau este eliberat unui vechi, 'lanţul de blocuri trebuie modificat'. Astfel, la alocarea unui nou bloc de memorie, trebuie să ţineţi cont de următoarele:

• Spaţiul liber în care este alocat noul bloc este mărginit de cel mult două blocuri vecine. Secţiunile de gestiune ale acestor vecini trebuie modificate astfel:
  • Indexul blocului următor din structura de gestiune a blocului din stânga trebuie să indice către noul bloc. Dacă blocul din stânga nu există, atunci este modificat indicele de start.
  • Indexul blocului precedent din structura de gestiune a blocului din dreapta trebuie să indice către noul bloc. Dacă blocul din dreapta nu există, atunci nu se întâmplă nimic.
• Secţiunea de gestiune a noului bloc va conţine indicii celor doi vecini, sau 0 în locul vecinului care lipseşte.

La eliberarea unui bloc, trebuie modificate secţiunile de gestiune a vecinilor într-o manieră similară ca la adăugare.

Programul vostru va trebui să implementeze o serie de operaţii de lucru cu arena, care vor fi lansate în urma comenzilor pe care le primeşte la intrare. Fiecare comandă va fi dată pe câte o linie, şi rezultatele vor trebui afişate pe loc. Secţiunea următoare prezintă sintaxa comenzilor posibile şi formatul de afişare al rezultatelor.

Programul vostru va trebui să accepte următoarele comenzi la intrare:

1. INITIALIZE <N>
   • Această comandă va fi apelată prima, şi va trebui să realizeze iniţializarea unei arene de dimensiune N octeţi. Prin iniţializare se înţelege alocarea dinamică a memoriei necesare stocării arenei, setarea fiecărui octet pe 0, şi iniţializarea lanţului de blocuri (setarea indicelui de start pe 0).
   • Comanda nu va afişa nici un rezultat.
2. FINALIZE
   • Această comandă este apelată ultima, şi va trebui să elibereze memoria alocată la iniţializare şi să încheie programul.
   • Comanda nu va afişa nici un rezultat.
3. DUMP
   • Această comandă va afişa întreaga hartă a memoriei, aşa cum se găseşte în acel moment, octet cu octet. Vor fi afişaţi câte 16 octeţi pe fiecare linie, în felul următor:
     • La începutul liniei va fi afişat indicele curent, în format hexazecimal, cu 8 cifre hexa majuscule.
     • Apoi este afişat un TAB ('\t') , urmat de 16 octeţi, afişati separaţi printr-un spaţiu şi în format hexazecimal, cu 2 cifre hexa majuscule fiecare. Între cel de-al 8-lea şi cel de-al 9-lea octet se va afişa un spaţiu suplimentar.
     • Pe ultima linie, indiferent de numărul de octeţi din arenă, se va afişa indexul ultimului octet din arenă + 1 (practic, dimensiunea arenei), în format hexazecimal cu 8 cifre hexa majuscule.
4. ALLOC <SIZE>
   • Comanda va aloca SIZE octeţi de memorie din arenă. Ea va trebui să găsească o zonă liberă suficient de mare (care să încapă SIZE octeţi + secţiunea de gestiune), şi să rezerve un bloc 'la începutul' zonei (nu în mijloc, nu la sfârşit). Va trebui folosită prima zonă liberă validă, într-o căutare de la stânga la dreapta.
   • Comanda va afişa, în format zecimal, indexul de început al blocului alocat în arenă, sau 0 dacă nu a fost găsită nici o zonă liberă suficient de mare în arenă. 'Atenţie:' Va trebui să afişaţi indexul secţiunii de date din noul bloc, şi nu al secţiunii de gestiune.
5. FREE <INDEX>
   • Comanda va elibera blocul de memorie al cărei secţiuni de date începe la poziţia INDEX în arenă. Practic, INDEX va fi o valoare care a fost întoarsă în prealabil de o comandă 'ALLOC'. În urma execuţiei acestei comenzi, spaţiul de arenă ocupat de vechiul bloc va redeveni disponibil pentru alocări ulterioare.
   • Comanda nu va afişa nici un rezultat.
6. FILL <INDEX> <SIZE> <VALUE>
   • Comanda va seta SIZE octeţi consecutivi din arenă, începând cu indexul INDEX, la valoarea VALUE, cuprinsă între 0 şi 255 inclusiv. Atenție, această comandă poate modifica și octeți de gestiune, nu numai octeți de date. În acest caz, se garantează ca arena nu va deveni coruptă după o serie de comenzi FILL consecutive.
   • Comanda nu va afişa nici un rezultat.
7. SHOW <INFO>
   • Comanda va afişa informaţii statistice despre starea arenei. INFO poate fi una din următoarele:
     1. FREE
        • Vor fi afişaţi (în format zecimal) numărul de octeţi liberi din arenă, împreună cu numărul de regiuni (zone continue) libere din arenă sub forma următoare:

          <nblocks> blocks (<nbytes> bytes) free

     2. USAGE
        • Vor fi afişaţi, pe câte o linie:
          • Numărul de octeţi folosiţi din arenă (numai secţiunile de date)
          • Eficienţa utilizării (în procente), egală cu numărul de octeţi folosiţi raportat la numărul de octeţi rezervaţi (care nu sunt liberi)
          • Fragmentarea (în procente), egală cu numărul de zone libere - 1, raportat la numărul de blocuri alocate. Pentru o arenă fără nici un bloc alocat, fragmentarea va fi considerată 0.
        • Formatul afişării este:

          <nblocks> blocks (<nbytes> bytes) used
          <eff>% efficiency
          <fragm>% fragmentation

     3. ALLOCATIONS
        • Vor fi afişate pe câte o linie, zonele libere şi alocate, în ordinea în care sunt aşezate în arenă. Fiecare linie va fi de forma:

          {FREE|OCCUPIED} <N>

        • unde { .. | .. } reprezintă faptul că doar una dintre valori va fi afişată. N reprezintă dimensiunea (nenulă), în octeţi, a zonei respective.

În această secţiune sunt ilustrate câteva exemple de rulare a programului, pentru a înţelege mai bine modul în care programul vostru trebuie să se comporte. Fiecare exemplu este urmat apoi de câteva explicaţii.

INITIALIZE 100
ALLOC 13
16
FILL 16 13 255
DUMP
00000000 04 00 00 00 00 00 00 00 00 00 00 00 19 00 00 00
00000010 FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00
00000064
FREE 16
ALLOC 50
16
ALLOC 40
0
ALLOC 30
0
ALLOC 20
78
FILL 78 20 127
DUMP
00000000 04 00 00 00 42 00 00 00 00 00 00 00 3E 00 00 00
00000010 FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 04 00 00 00 20 00 00 00 7F 7F
00000050 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F
00000060 7F 7F 00 00
00000064
FREE 16
FREE 78
FINALIZE

Observaţii:

• Comenzile (intrarea) este marcată cu albastru, iar ieşirea cu negru. Programul vostru nu trebuie să afişeze nimic altceva în afara a ce este ilustrat în acest exemplu.
• În output-ul de DUMP, au fost marcate cu verde zonele de gestiune. În primul dump, în primul chenar se poate recunoaşte indexul de start, în al doilea chenar secţiunea de gestiune a blocului alocat. Cu roşu au fost figurate datele utilizatorilor.
• Se poate observa că cererile de alocare prea mari au fost respinse, afişându-se 0 (care este un index de date invalid, pentru că pe poziţia 0 stă indexul de start, şi nu se poate aloca memorie în acea zonă).

INITIALIZE 100
ALLOC 10
16
ALLOC 10
38
ALLOC 10
60
ALLOC 10
82
ALLOC 10
0
FREE 16
FREE 60
FILL 38 10 255
FILL 82 10 255
DUMP
00000000 1A 00 00 00 1A 00 00 00 00 00 00 00 16 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 46 00 00 00 00 00
00000020 00 00 16 00 00 00 FF FF FF FF FF FF FF FF FF FF
00000030 46 00 00 00 1A 00 00 00 16 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 1A 00 00 00 16 00
00000050 00 00 FF FF FF FF FF FF FF FF FF FF 00 00 00 00
00000060 00 00 00 00
00000064
FINALIZE

În acest exemplu se poate observa modul în care sunt actualizate secţiunile de gestiune ale vecinilor blocurilor eliberate, pentru a le înlătura din lanţul de blocuri. De asemenea, se poate observa în dump faptul că un bloc eliberat nu este modificat (resetat pe 0, de exemplu).

INITIALIZE 100
ALLOC 20
16
ALLOC 20
48
SHOW FREE
1 blocks (32 bytes) free
SHOW USAGE
2 blocks (40 bytes) used
58% efficiency
0% fragmentation
SHOW ALLOCATIONS
OCCUPIED 4 bytes
OCCUPIED 32 bytes
OCCUPIED 32 bytes
FREE 32 bytes
FREE 16
SHOW FREE
2 blocks (64 bytes) free
SHOW USAGE
1 blocks (20 bytes) used
55% efficiency
100% fragmentation
SHOW ALLOCATIONS
OCCUPIED 4 bytes
FREE 32 bytes
OCCUPIED 32 bytes
FREE 32 bytes
FINALIZE

În acest exemplu se poate observa cum se modifică statisticile arenei pe măsură ce blocurile sunt alocate şi eliberate.

Se va acorda un bonus de 20 de puncte (pe lângă faimă şi respect :) ), dacă se vor implementa, pe lângă comenzile standard prezentate mai devreme, şi următoarele comenzi:

1. ALLOCALIGNED <SIZE> <ALIGN>
   • Această comandă va funcţiona ca ALLOC, cu excepţia faptului că indexul returnat va trebui să fie aliniat la ALIGN octeţi, unde ALIGN este o putere a lui 2 (poate fi 1, 2, 4, 8, etc.). Un index INDEX este aliniat la ALIGN octeţi dacă INDEX % ALIGN == 0.
2. REALLOC <INDEX> <SIZE>
   • Această comandă va realoca o zonă de memorie întoarsă în prealabil la adresa INDEX într-un nou spaţiu de memorie de dimensiune SIZE şi va afişa indexul secţiunii de date a noului bloc alocat. De asemenea, va copia datele aflate în vechiul bloc în noul bloc. Daca SIZE este mai mic decât dimensiunea originală, vor fi copiaţi numai SIZE octeţi (va avea loc o trunchiere).
   • Atenţie: Pentru găsirea unei zone de memorie libere va trebui să reluaţi procedura de căutare de la stânga la dreapta. Nu este valid să verificaţi că în locul curent există deja spaţiu pentru expansiune / micşorare.
3. SHOW MAP <LENGTH>
   • Comanda va afişa pe mai multe linii un şir de LENGTH caractere, fiecare caracter fiind fie “*” sau ”.”, care va descrie zonele libere sau ocupate din arenă. Un caracter este “*” dacă în zona descrisă de el se află cel puţin un octet rezervat, altfel el va fi ”.”. Fiecare linie va afişa maxim 80 de astfel de caractere. Dacă dimensiunea arenei este N, atunci un caracter va reprezena x = N / LENGTH octeți. Dacă cel puțin unul din cei x octeți este ocupat, se va afișa “*”, altfel ”.”. Atenție, x poate fi și subunitar.

INITIALIZE 100
ALLOCALIGNED 10 32
32
SHOW ALLOCATIONS
OCCUPIED 4 bytes
FREE 16 bytes
OCCUPIED 22 bytes
FREE 58 bytes
FILL 32 10 255
SHOW MAP 50
**........***********.............................
SHOW MAP 31
**....********.................
SHOW MAP 2
*.
SHOW MAP 200
********................................****************************************
****............................................................................
........................................
DUMP
00000000 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 16 00 00 00
00000020 FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00
00000064
REALLOC 32 50
16
DUMP
00000000 04 00 00 00 00 00 00 00 00 00 00 00 3E 00 00 00
00000010 FF FF FF FF FF FF FF FF FF FF 00 00 16 00 00 00
00000020 FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060 00 00 00 00
00000064
SHOW MAP 100
******************************************************************..............
....................
FINALIZE

Puteti folosi scheletul de cod care se gaseste aici.

Testarea temei se va face folosind un script de evaluare automată, ce poate fi descărcat de aici.

• Arhiva se dezarhivează în directorul vostru de lucru (acolo unde este compilat executabilul ./allocator).

• În acest director trebuie să aveți conținutul temei voastre: surse, fișier Makefile și README.

• Arhiva conţine un fişier check.sh, din care se porneşte operaţia de testare (./check.sh).

• Arhiva conține testele încadrate în categoriile basic, advanced și bonus. Testele random vor fi generate de fiecare dată când se va rula check.sh.

• Dimensiunea testelor NU este relevanta (deoarece ar trebui sa aveti arena alocata dinamic). Daca doriti sa vedeti aceste dimensiuni, puteti sa consultati fisierele din _tests pentru testele din arhiva, iar pentru cele random aceste limite de gasesc in functia generate_random din check.sh.

• Dacă apar erori şi testele eşuează, puteţi să vă uitaţi în directorul _tests şi să comparaţi rezultatele voastre (fişierele .out), cu cele ale implementării de referinţă (fişierele .ref).

• Arhiva include şi un binar al implementării de referinţă (./reference), care este folosit intern de tester. Puteţi de asemenea să-l rulaţi separat şi să experimentaţi cu el şi alte situaţii.

• Arhiva mai conține un script numit cs.py, care este varianta adaptată pentru C a checkerului de C++ de aici aici . Checkerul va rula intern acest script. Puteți să îl rulați manual astfel python cs.py sursa.c sau python cs.py antet.h.

• Criteriile de notare sunt următoarele:
  • 90 puncte - testele automate din arhiva de testare.
  • 4 puncte - explicaţiile din README
  • 6 puncte - aspectul codului sursă
  • 20 puncte - implementarea bonusului

• Teste basic: 15 puncte
• Teste advanced: 30 puncte
• Teste random: 45 puncte
• Implementare bonus: 20 puncte

Se pot aplica depunctări suplimentare:

• calitatea şi eficienţa implementării
  • 5 puncte dacă codul nu este modularizat
    • 2 puncte dacă codul este modularizat, dar folosește funcții foarte lungi
    • 5 puncte pentru warning-uri de compilare
• utilizarea corespunzătoare a memoriei
  • 70 puncte dacă memoria nu a fost alocată dinamic
  • 20 puncte dacă memoria a fost alocată dinamic, dar nu s-a eliberat la final memoria
  • 10 puncte dacă programul are accese nevalide la memorie (testat cu valgrind)
• nerespectarea tipului de arenă menționat în enunț
  • anularea întregului punctaj

Punctajul pe teste este cel acordat pe vmchecker. Echipa de corectare își rezervă dreptul de a depuncta pentru orice încercare de a trece testele fraudulos (de exemplu prin hardcodare).

Punctajul pe README va fi stabilit în urma corectării manuale. Checker-ul doar vă reamintește dacă nu aveți README sau aveți un README gol în arhivă, pentru a submite unul în arhiva finală.

Checker-ul va încerca să detecteze în mod automat cele mai frecvente greșeli de coding style. Dacă checkerul acordă punctaj 0 pe coding style, acesta este final . În caz contrar, va acorda punctaj maxim, iar punctajul final pe coding style va fi acordat după corectarea manuală.

Se pot aplica depunctări care nu apar în lista de mai sus!

În total se pot obține până la 200p pe proiect, pentru anumite soluții deosebite.

Soluțiile eligibile sunt cele care obțin cele 120 de puncte menționate anterior.

Numim soluție deosebită o soluție care în plus poate avea următoarele atribute (nu neapărat pe toate): * prezintă un mod eficient de organizare al proiectului, de lucru cu pointeri și cu memoria * prezintă funcționalități în plus (nemenționate în enunț) și care sunt relevante pentru alocator de memorie; aceste funcționalități noi trebuie să fie însoțite și de o metodă de testare (de exemplu prin crearea unor fișiere de test noi care să cuprindă noile comenzi) * prezintă o interfață ușor de folosit (de exemplu sub forma unei biblioteci dinamice partajate)

Studentul poate propune orice alt extra bonus pe care îl consideră relevant pentru acest subiect (alocator de memorie).

Pentru a explica de ce credeți ca soluția voastră trebuie luată în considerare pentru extra bonus, creați o secțiune Extra bonus în README și explicați pe larg ce ați facut.

Pentru funcționalitățile noi create se pot aplica depunctări (cele menționate mai sus), dar care nu se aplică pentru cele 120 de puncte.

Notarea este subiectivă și va fi facută în urma prezentării proiectului.

În prima săptămână de după vacanța de iarnă, proiectul se va susține în fața celor doi responsabili. Această dată va fi specificată ulterior în enunț și pe forum.

Un proiect neprezentat este notat cu punctaj NUL!

Punctajul final pe proiect este cel acordat în urma prezentării și poate să difere de cel de pe vmchecker.

• Regulamentul general al proiectului se gășeste aici.

• Proiectul se va implementa DOAR în limbajul C. Va fi compilat și testat DOAR într-un mediu LINUX. Nerespectarea acestor reguli aduce un punctaj NUL.

• Proiectul va fi trimis DOAR pe vmchecker, sub forma unei arhive ZIP. Nerespectarea acestei reguli aduce un punctaj NUL pe temă.

• Fișierele proiectului trebuie OBLIGATORIU împachetate într-o arhiva de tip '.zip', cu numele Grupa_NumePrenume_Proiect.zip (exemplu: 316CA_PopescuGigel_Proiect.zip).

• Arhiva va trebui să conţină in directorul RADACINA doar urmatoarele:
  • 1. Codul sursă al programului vostru (fișierele .c și eventual .h).
  • 2. Un fișier Makefile care să conțină regulile build și clean. Regula build va compila programul într-un executabil cu numele allocator. Regula clean va șterge executabilul și eventual toate binarele intermediare (fișiere obiect) generate de voi.
  • 3. Un fișier README care să conțină prezentarea implementării alese de voi. Dacă ați implementat și bonusul, menționați acest lucru în README. NU copiați bucăți din enunț în README.
  • 4. Un fișier gol bonus dacă ați implementat și bonus-ul (folosit intern de vmchecker pentru a determina dacă trebuie să ruleze sau nu și aceste teste).
  • Nerespectarea regulilor 1 și 2 aduce un punctaj NUL pe proiect.

• Arhiva proiectuluu NU va conține fișiere binare. Nerespectarea acestei reguli aduce un punctaj NUL pe proiect.

• Un proiect care NU compilează pe vmchecker NU va fi punctat.

• Un proiect care compilează, dar care NU trece niciun test pe vmchecker, NU va fi punctat. Punctele pe teste sunt cele de pe vmchecker.

• Q: Diferente intre punctajul local si punctajul de pe vmchecker?

A: Dupa tema 2 ar trebui sa stiti deja care sunt problemele (undefined behaviour):p. Aveti grija sa NU cititi din zone de memorie neinitializate / invalide / dealocate in prealabil cu free etc.

• Q: SEGFAULT … ce fac?

A: Iau o pauza, beau o bere … apoi incerc sa depistez linia de cod care ar putea sa produca aceasta eroare.

1. pun printf-uri (neaparat terminate cu '\n', altfel nu se vor afisa ultimele mesaje cand programul crapa - exista si o explicatie pentru asta, nu neaparat importanta pentru nivelul la care se invata C in anul 1: stdout it's buffered)
2. folosesc gdb (poate fi mai greu, deoarece va veti lovi de cunostinte din anul 2 - incercati varianta cu printf-uri, daca nu iese cereti ajutor pe forum)

• Q: Cum verific daca am memory leaks?

A: Am grija ca numarul de alocari sa fie egal cu numarul de eliberari de memorie (vorbim doar de alocare dinamica). Folosesc valgrind ca sa confirm acest lucru:

darius@pc ~/project/skel $ sudo apt-get install valgrind
...
 
darius@pc ~/project/skel $ valgrind --version
valgrind-3.11.0
 
darius@pc ~/project/skel $ valgrind ./allocator < _tests/basic_1.in 
==19233== Memcheck, a memory error detector
==19233== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19233== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==19233== Command: ./allocator
==19233== 
 
// DE AICI INCEPE EXECUTIA NORMALA A PROGRAMULUI MEU (Ex. citeste date de la tastatura)
cmd = (INITIALIZE)
arg[0] = (INITIALIZE)
arg[1] = (100)
 
cmd = (ALLOC)
arg[0] = (ALLOC)
arg[1] = (13)
 
 ...
 
cmd = (FINALIZE)
arg[0] = (FINALIZE)
 
// AICI S-A INCHEIAT PROGRAMUL MEU, urmeaza un sumar de la valgrind
 
==19233== 
==19233== HEAP SUMMARY:
==19233==     in use at exit: 0 bytes in 0 blocks
==19233==   total heap usage: 31 allocs, 31 frees, 5,253 bytes allocated
==19233== 
==19233== All heap blocks were freed -- no leaks are possible
==19233== 
==19233== For counts of detected and suppressed errors, rerun with: -v
==19233== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Pentru verificarea memory leaks relevante sunt liniile urmatoare:

1. total heap usage: 31 allocs, 31 frees, 5,253 bytes allocated (mi se confirma ca am facut 31 de alocari si 31 de free-uri)
2. All heap blocks were freed – no leaks are possible (deoarece numerele sunt egale - am eliberat tot ce am alocat - nu am memory leaks)

P.S. Valgrind poate fi util si pentru alte situatii. Un exemplu foarte util este detectarea acceselor invalide la memorie (daca as fi avut as fi vazut multe mesaje de tip eroare inainte de HEAP SUMMARY). Rezolvarea acestor probleme m-ar putea scuti de situatia neplacuta in care obtin X puncte local si Y puncte pe vmchecker (Y « X).

• Q: ”./reference ⇒ nu se poate rula”

A:

Ce este reference? La ce e util? Unul dinstre autori a implementat tema, a compilat-o pe OS 32bit (conditiile de pe vmchecker). Dacă lucrați pe 64 de biți, este posibil să nu aveți instalate toate bibliotecile necesare pentru a rula executabile compilate pe 32 de biți.

Încercați să reproduceți exemplul următor (după ce ați dezarhivat arhiva cu checkerul):

Dacă ați reușit să rulați ca în exemplu, atunci aveți instalat tot ce trebuie pentru checker.

Dacă întâmpinați erori (ex. “No such file” - pare absurd, dar așa apare), atunci încercați una din soluțiile menționate pe acest link: How to run 32-bit app in Ubuntu 64-bit? .

• soluție 1 (recomandată)

        sudo apt-get update
        sudo apt-get install multiarch-support
 

• soluție 2

        sudo dpkg --add-architecture i386
        sudo apt-get update
        sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
 

Încercați pe rând câte o soluție. După fiecare soluție încercați să rulați reference ca în exemplul anterior.

Dacă nu ați reușit cu soluțiile menționate mai sus (sau pe acel link), postați pe forum un mesaj în care includeți și un printscreen cu terminal când rulați (pentru a ne da seama mai repede ce problemă aveți).

Otherwise… Google it's your best friend ! (after Gigel )