ErroriESuggerimenti < Labprog2

Tags: view all tags

__Memory Error (ME)__

   * Per permettervi di capire meglio perchè qualcosa non funziona ho creato un log degli errori di gestione di memoria evidenziati dal tool *valgrind* (vedi [[http://www.cprogramming.com/debugging/valgrind.html][Valgrind tutorial]])
   * Se valgrind si lamenta vi viene aggiunta un *ME* nel vostro risultato, date un'occhiata al vostro log di valgrind per scoprire dove può essere l'errore.
   * Ad esempio, se avete segmentation faults forse con il file ==valgrind.log== potete capire perchè e dove è successo
   * __NOTA:__ questi errori non vi penalizzano nella valutazione, ma servono solo a darvi maggiori indicazioni per scoprire perchè il vostro programma va in SF 

__SF e TF__

Mi hanno fatto notare che con il test globale anche un solo SF o TF fa fallire tutta una valutazione. 
Non mi è possibile fare i test separatamente, mandate una patch che elimina (basta che la rinomini) la funzione che volete che non sia testata.

__SEGMENTATION FAULT e NON COMPILA__
   * In questi casi vuol dire che c'e' un errore. Il fatto che sulla vostra macchina il programma abbia funzionato non vuol dire che l'errore non ci sia. Abbiamo quindi pensato di permettervi di recuperare:
      * Avete la possibilità di trovare il baco e mandarmi una patch che lo corregga.
         * per creare la patch usate il comando 
         <pre style="background:yellow">diff -ubBw filevecchio.c filenuovo.c > file.patch </pre> 
      * Il modulo otterrà il punteggio dato dai test meno una penalizzazione che verrà decisa caso per caso.
      * La patch deve essere piccolissima (non riscrivete tutto il modulo).
      * AVETE 30 GIORNI DI TEMPO
      * per i moduli 1 e 2 fanno fede i test di Sterbini.
      * per i moduli 3 e 4 potremmo far girare i test su più macchine. In tal caso vale la situazione peggiore (ovvero basta un SEGFAULT su una delle macchine per dover cercare il baco)
   * alcuni non hanno mandato il file ==LPC<nop>_M1_Include.h==, lo mandino

__TIMEOUT O FREE ERROR__
   * Talvolta fate un errore deallocando una zona non allocata (ad esempio facendo free di un puntatore non inizializzato). In questi casi viene un errore che non appare nei log (perchè non stampa su stderr) e il programma si blocca. Dopo 5 secondi il processo viene ucciso e vi appare un errore TIMEOUT.

__COME CERCARE ERRORI DI USO DELLA MEMORIA__
   * Usate la libreria Electric Fence che controlla se sbordate dalle aree di memoria allocata.
      * la documentazione la trovate con 
      <pre style="background:yellow">man efence</pre> 
      * eseguite il programma scrivendo
      <pre style="background:yellow">LD_PRELOAD=libefence.so.0.0 ./TestM1 </pre> 
   * eseguite passo passo il programma col debugger per capire su quale istruzione fa casino
      <pre style="background:yellow">gdb ./TestM1 </pre> 
      <pre style="background:yellow">run </pre> 
   * eseguite il programma con *valgrind* per capire su quale istruzione fa casino
      <pre style="background:yellow">valgrind -q ./TestM1 </pre> 

__NOTA__
   * non vi preoccupate dei warning che seguono, non vengono considerati come errore
   * abbiamo linkato una versione vuota delle funzioni in modo da far compilare anche a chi ha consegnata solo una, dal prossimo modulo dovrete inserire voi una versione vuota delle funzioni che non implementate
<pre>
/usr/bin/ld: Warning: size of symbol `CreateDatabaseFile' changed from 2132 in lib/Modulo1.a(LPC_CreateDBF?.o) to 10 in obj/LPC_Dummy.o 
/usr/bin/ld: Warning: size of symbol `DeleteDatabaseFile' changed from 903 in lib/Modulo1.a(LPC_DeleteDBF?.o) to 10 in obj/LPC_Dummy.o
</pre>

Non avete seguito molto bene le specifiche
   * a breve pubblicheremo una valutazione precisa dell'importanza che diamo al non aderire alle specifiche.
   * per questo modulo e per il ModuloDue la valutazione di aderenza alle specifiche non viene applicata
   * nei moduli 3 e 4 verrà applicata anche l'aderenza alle specifiche


-- Users.AndreaSterbini - 05 May 2006