Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ SQL » Sql crash in 64 bit machine
Sql crash in 64 bit machine [message #36568] Sun, 10 June 2012 10:27 Go to next message
forlano is currently offline  forlano
Messages: 1189
Registered: March 2006
Location: Italy
Senior Contributor
Hello,

it is the second time my customer signal a crash of my program under a 64 bit windows. It seems the problem reside in Sqlite plugin compiled at 32 bit (the whole program is compiled at 32 bit).
Is this normal? Does it mean I must provvide a version for 32 bit and 64 bit?

Thanks,
Luigi
Re: Sql crash in 64 bit machine [message #36569 is a reply to message #36568] Sun, 10 June 2012 10:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
forlano wrote on Sun, 10 June 2012 04:27

Hello,

it is the second time my customer signal a crash of my program under a 64 bit windows. It seems the problem reside in Sqlite plugin compiled at 32 bit (the whole program is compiled at 32 bit).
Is this normal? Does it mean I must provvide a version for 32 bit and 64 bit?

Thanks,
Luigi


No, 32-bit executables run in 64-bit windows just fine, there should be no difference.

I would say that perhaps you are doing something that makes sqlite occassionally crash, or that the cause of crash is in your code, but it is revealed in sqlite - you are sharing the address space with sqlite, so e.g. end of buffer overwrite in your code can corrupt sqlite memory...
Re: Sql crash in 64 bit machine [message #36572 is a reply to message #36569] Sun, 10 June 2012 18:08 Go to previous messageGo to next message
forlano is currently offline  forlano
Messages: 1189
Registered: March 2006
Location: Italy
Senior Contributor
mirek wrote on Sun, 10 June 2012 10:39


No, 32-bit executables run in 64-bit windows just fine, there should be no difference.



Thanks.
I thought and hoped the same. In 32 bit the program is stable and do not crash. In 64 bit it does not work at the very beginning when the database is created.
The log file consists of rows similar to these:

* F:\orion\orion.exe 09.06.2012 19:56:30, user: User

SQL* create table TORNEO (  ID integer primary key )
ERROR library routine called out of sequence(0): Preparing: create table TORNEO (  ID integer primary key )
SQL* alter table TORNEO add  NAME text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  NAME text
SQL* alter table TORNEO add  PLACE text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  PLACE text
SQL* alter table TORNEO add  HOSTFED text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  HOSTFED text
SQL* alter table TORNEO add  DATEB text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  DATEB text
SQL* alter table TORNEO add  DATEE text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  DATEE text
SQL* alter table TORNEO add  PARBITER text
ERROR library routine called out of sequence(0): Preparing: alter table TORNEO add  PARBITER text
SQL* alter table TORNEO add  DARBITER text


and this is the code that create it

void vegadb::SetDatabase(String dbname)
{
    if (sqliteVT.IsOpen()) sqliteVT.Close();
//	if(!sqliteVT.Open(ConfigFile(dbname))) {
    if (!FileExists(dbname)) {
		if(!sqliteVT.Open( dbname )) {
			Exclamation("Can't create or open database file");
			return;
		}
		SQL = sqliteVT;
		sqliteVT.SetTrace();
		SqlSchema sch(SQLITE3);
		All_Tables(sch);
		Sqlite3PerformScript(sch.Upgrade());
		Sqlite3PerformScript(sch.Attributes());  
	}
	else {
		if(!sqliteVT.Open( dbname )) {
			Exclamation("Can't create or open database file");
			return;
		}
		SQL = sqliteVT;
		sqliteVT.SetTrace();
		SqlSchema sch(SQLITE3);
	}
	SQL.ClearError();
}


I am sure these info are not enough to catch the problem, but maybe somebody got a similar problem.
Luigi
Re: Sql crash in 64 bit machine [message #36580 is a reply to message #36572] Mon, 11 June 2012 10:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13984
Registered: November 2005
Ultimate Member
This actually looks like database was opened twice or something like that... Have you googled these errors?
Re: Sql crash in 64 bit machine [message #36582 is a reply to message #36580] Mon, 11 June 2012 14:48 Go to previous message
forlano is currently offline  forlano
Messages: 1189
Registered: March 2006
Location: Italy
Senior Contributor
mirek wrote on Mon, 11 June 2012 10:14

This actually looks like database was opened twice or something like that... Have you googled these errors?


Yes, I misuse the library

-----------
Error Code SQLITE_MISUSE (21) "Library routine called out of sequence"

The SQLITE_MISUSE error code is returned when you misuse the SQLite library in some way. SQLite does not guarantee that it will detect misuse, so you should not depend on this behavior in any way. The SQLITE_MISUSE error code is intended to help you find the bugs in your code.

Here are some possible causes of SQLITE_MISUSE:

Calling any API routine with an sqlite3* pointer that was not obtained from sqlite3_open() or sqlite3_open16() or which has already been closed by sqlite3_close().

Trying to use the same database connection at the same instant in time from two or more threads.

Calling sqlite3_step() with a sqlite3_stmt* statement pointer that was not obtained from sqlite3_prepare() or sqlite3_prepare16() or that has already been destroyed by sqlite3_finalize().

Trying to bind values to a statement (using sqlite3_bind_...()) while that statement is running.
-----------

I'll check better.
Thank you,
luigi

Previous Topic: SqlBinary and Postgres 9
Next Topic: Can I use netSQLite to solve the problem of sharing SQLite database?
Goto Forum:
  


Current Time: Thu Jun 13 18:19:11 CEST 2024

Total time taken to generate the page: 0.01820 seconds