[C++] Persistence Layer con supporto ad AES

[Opcode]

Sera,

stò lavorando da più di una settimana oramai, sul design di un semplice persistence layer.

Quello che vorrei ottenere è una classe che gestisca in modo del tutto trasparente la persistenza dei dati. Inoltre avevo intenzione di usufruire di una delle librerie online per crittare i dati tramite l'algoritmo di Rijndael (AES).

Come implementazione dell'algoritmo AES, visto che mi serve solo per criptare e decriptare, ho deciso di usare questo (http://www.codeproject.com/KB/security/aes.aspx) (dopo aver anche provato l'implementazione di Chris Lomont reperibile qui (http://www.lomont.org/Software/Misc/AES/AES.php)).

Di seguito linko i due file in cui si trovano la dichiarazione e la definizione della classe PersLayer:
PersLayer.cpp (http://paste.pocoo.org/show/3WjePPNy8W5PLVWLKLDl/)
PersLayer.h (http://paste.pocoo.org/show/oGEj7xPrmUy02N8mzKNG/)

Il file main è semplicemente:
#include "PersLayer.h"
#include <iostream>

int main()
{
try {
PersLayer("test.txt", "test.dat", "aaaaaabbbbbbcccc");
}
catch (std::exception &ex) {
std::cout << ex.what() << std::endl;
}

getchar();
return (0);
}

Ho deciso di permettere la creazione dei valori default da un file plain-text affinchè non sia necessario creare i nuovi file .dat codificando tutte le chiavi valore. Attualmente è solo una bozza, il metodo PersLayer::parse non parsa affatto il contenuto, ma si limita a tentare di stamparlo dopo una conversione da unsigned char a char per poterlo stampare correttamente.

Purtroppo...
all'avvio del programma l'applicazione và in crash con questo messaggio:
'Test.exe': Loaded 'C:\Users\Billi\Documents\Visual Studio 2010\Projects\Test\Debug\Test.exe', Symbols loaded.
'Test.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'Test.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'Test.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'Test.exe': Loaded 'C:\Windows\System32\msvcp100d.dll', Symbols loaded.
'Test.exe': Loaded 'C:\Windows\System32\msvcr100d.dll', Symbols loaded.
First-chance exception at 0x75be9617 in Test.exe: Microsoft C++ exception: std::ios_base::failure at memory location 0x0013f814..
HEAP[Test.exe]: Heap block at 004E5D20 modified at 004E5D57 past requested size of 2f
Windows has triggered a breakpoint in Test.exe.

This may be due to a corruption of the heap, which indicates a bug in Test.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Test.exe has focus.

The output window may have more diagnostic information.
The program '[0x148] Test.exe: Native' has exited with code 0 (0x0)

Non capisco dove stia il problema. Pensavo potesse riguardare il tentativo di stampare in PersLayer::parse, ma non è quello. Il debugger mi dà le seguenti informazioni (http://img691.imageshack.us/img691/1346/schermata1k.png).
Purtroppo non riesco a ricavare molto altro dal debugger.
Per semplificare il lavoro di chi vorrà aiutarmi ho deciso di caricare la soluzione visual studio reperibile qui (http://rapidshare.com/files/419045624/Test.zip).

Ringrazio in anticipo chiunque potrà aiutarmi, non mi sembra di sbagliare nulla di chè, evidentemente c'è qualche errore che non vedo.

[tomminno]

Hai provato con il debug passo passo?
Purtroppo nella schermata hai escluso la parte che poteva essere più utile: lo stack trace.

Non so a cosa ti serva di preciso la persistenza ma potresti pensare di utilizzare Sqlite per mantenere i dati.

Comunque io eliminerei quegli inutili try/catch/throw.

[Opcode]

Hai provato con il debug passo passo?
Purtroppo nella schermata hai escluso la parte che poteva essere più utile: lo stack trace.
Ecco a te (http://img338.imageshack.us/img338/6913/schermata2w.png).

Non so a cosa ti serva di preciso la persistenza ma potresti pensare di utilizzare Sqlite per mantenere i dati.Verissimo. Ma pensavo di svilupparlo non solo per esigenza (devo salvare alcune preferenze dell'utente) ma anche per imparare qualcosa di nuovo, e migliorare la mia conoscenza del C++. E' per una mia applicazione non per uso commerciale, quindi ho tempo di stare a studiare e sperimentare, purtroppo questo brutto errore è fuori dalla mia portata, ho provato di tutto ma proprio non capisco dove stia il problema. Solitamente gli errori che ottengo sono in fase di linking/debugging, non ho esperienza con questo genere di errori (non sò quale sia il termine per descriverli, errori a runtime?).

Comunque io eliminerei quegli inutili try/catch/throw.
Si, prima sollevavo l'eccezione Exception, quella dello scorso thread per quello li avevo messi, poi ho deciso di minimizzare il codice per venire a capo del problema e quelli li ho lasciati rilanciando semplicemente l'eccezione catturata (inutilmente, visto che andrebbe da sola al contesto successivo, ma vabbè).

Grazie, se hai bisogno di altre info, o hai qualche possibile soluzione, sono prontissimo a sperimentarla :)

Buona notte.

[tomminno]

Purtroppo non si vede la linea comunque l'errore te lo dà su una delle 2 delete alla fine del metodo generateBinaryFile.
Ma sei proprio sicuro che dataIn e dataOut debbano avere la stessa dimensione?
Dovresti guardare la documentazione della libreria.
Io comunque mi affiderei a qualcosa di meglio tipo cryptopp.

Solitamente gli errori che ottengo sono in fase di linking/debugging, non ho esperienza con questo genere di errori (non sò quale sia il termine per descriverli, errori a runtime?).


In questi casi vai di break point e F10

[Opcode]

Purtroppo non si vede la linea comunque l'errore te lo dà su una delle 2 delete alla fine del metodo generateBinaryFile.
Ma sei proprio sicuro che dataIn e dataOut debbano avere la stessa dimensione?
Stando agli esempi riportati nella presentazione della libreria si
char szDataIn1[49] = "ababababccccccccababababccccccccababababcccccccc";
char szDataIn[49];
char szDataOut[49];
memset(szDataIn, 0, 49);
memset(szDataOut, 0, 49);

Dovresti guardare la documentazione della libreria.
ùhm, documentazione... si... :fagiano:

Io comunque mi affiderei a qualcosa di meglio tipo cryptopp.
Se non risolvo, anche io :D

In questi casi vai di break point e F10
Perfetto, ho fatto cosi, e sono riuscito ad individuare gli operatori delete [] a cui si riferisce il debugger nello stack trace, sono quelli di PersLayer::parse e quelli di PersLayer::generateBinaryFile, il che comunque mi suona strano, cioè alloco la memoria, e la dealloco, che mai farò di cosi illegale :confused:

Secondo te è colpa di un improprio uso della libreria?
Se commento quegli operatori di delete [] (cosa comunque non ammissibile, visto che non dealloco la memoria con un conseguente memory leak) non và in crash (anche se non ottengo il risultato corretto).