aurusfeles wrote:Actually, the code is really huge, I can't post it here. Is there any way to detect where the problem is, using Visual Studio or anything else?
Well, if you can't boil down the code producing the problem to a reasonable size, there is little chance to help you to identify the cause of the problem. As said before stack corruption can be the result of different effects. Maybe your code writes to some arrays using indexes out of bounds, maybe your code allocates very large objects on the stack and thus exceeds the available stack size ... how should I know?
aurusfeles wrote:Til then, i'm using Sqlite directly (I don't use any specific feature of wxsqlite, so it's a bit of overkill), and the stack corruption is "gone".
Using SQLite directly reduces the amount of stack space needed, since SQLite allocates memory on the heap. Using a local variable within a method always allocates memory on the stack. So, if the cause of the problem is really a too small stack size, you could either increase the stack size in Visual Studio:
Code: Select all
Properties -> Configuration Properties -> Linker -> System -> Stack Reserve Size
or make the wxSQLite3Database object a class member instead of a local variable or use a dynamic object
Code: Select all
wxSQLite3Database* db = new wxSQLite3Database();
If on the other hand your code really corrupts the stack, i.e. by writing array elements out of bound, the above measures would not cure the original cause of the problem, and you could run out of luck at a later time at a different place in your application.
Regards,
Ulrich