When I click on "Show Unassigned", Python crashes 
(Invalid Read ..., not a Python exception). I'm using: -

roundup 0.5.1(classic template), pysqlite 0.3.1, 
SQLite 2.7.2, ActivePython 2.2.1, Windows 2000 SP2

Logged In: NO 

I can be reached at kazar1my@yahoo.co.uk

Logged In: YES 
user_id=6405

What is the exact error you get? I'm not familiar with any "Invalid Read ..."   
errors. By the comment "not a Python exception" I presume you mean that  
python didn't catch the error and raise an exception. If this is the case,  
then it sounds like an sqlite or pysqlite bug... 
 

Logged In: YES 
user_id=6405

Did the unit tests run without error? 
 

Logged In: YES 
user_id=638767

It's one of those 'Invalid Instruction' errors; a relative of the 
BSOD. Yes, it probably is an SQLite bug. IMHO though, it 
might be due to a malformed SELECT statement in roundup.

As for tests, pysqlite runs all tests without error. I haven't 
run roundup tests yet.

Give me an hour or so and I'll get you the exact error 
(though I don't think it'll help much) and run the roundup 
tests. I'm not at home right now.

If it helps, I just changed the backend used from bsddb to 
sqlite (export old database --> import).

Logged In: YES 
user_id=6405

Hurm. Please do try running the Roundup unit tests - they have pretty good  
coverage of the hyperdb. 
  
We use sqlite in our production trackers, though in our case they're on  
Unix. We haven't experienced a crash in the month of operation so far  
though, so I expect it's got something to do with sqlite-on-Windows. 
 
Thanks for offering to track down the problem - a good place to start is the 
unit tests, assuming they can cause the same error. 
 

Logged In: YES 
user_id=638767

The error is as follows: -

python.exe - Application Error
The instruction at "0x00000000" referenced memory 
at "0x00000000". The memory could not be "read".

It most likely is an SQLite bug (if I'm reading the MSVC debugger 
Call Stack correctly).

All the roundup tests, including the sqlite tests, run without errors.

Sorry but no guarantees on tracking down the bug. It isn't a 
critical bug for me. I hope it doesn't make a hash of my data, 
though.

Note that the opinion I had (on the malformed SELECT 
statement) was just a guess.

Logged In: YES 
user_id=6405

That's quite concerning. Can you provide a script that I could send to the 
[py]sqlite people that would indicate how to reproduce the error? Starting 
with "download pysqlite and roundup" going to "click on this link and see it 
break". That'd help immensely, and hopefully the [py]sqlite people can 
figure what's wrong. 
 

Logged In: YES 
user_id=638767

Script?! Hunting down the bug would be more fun :-).

So here goes...

After turning on __debug__ in roundup, I decided on the 
following sequence of events in reproducing the bug:

First, I went to the front page:

http://127.0.0.1:8080/Personal/

Then, I typed in the following URL:

http://127.0.0.1:8080/Personal/issue?:filter=status,assignedto&:col
umns=id,activity,title,creator,status&status=8&assignedto=-1

Roundup will eventually send the following SQL statement:

select id from _issue  where (_status in (8)) and (_assignedto in 
() or _assignedto is NULL)

Voila! SQLITE.DLL crashes. BTW, the MSVC debugger 
confirmed the GPF was in SQLITE.DLL.

To confirm this, I run sqlite on the database(db):

$ sqlite db
sqlite> select id from _issue  where (_status in (8)) and 
(_assignedto in () or _assignedto is NULL);

Same thing happens. I managed to reduce the buggy SQL 
statement to:

sqlite> select id from _issue  where _status in (8) and 
_assignedto in ();

Note that:

sqlite> select id from _issue  where (_status in (8)) and 
(_assignedto is NULL);

works!

Some observations: -
  1. Apparently, the bug only triggers when unassigned=-1 and 
status=subset of the set of status values in the database where an 
issue exists with that status. Here, the set would be (2, 5, 8).
  2. For consistent results, the select statement must be the first 
SQL statement after typing in "sqlite db". There are situations 
where the buggy SQL statement works, though I've not gotten 
around to formalising them.

An important point (perhaps) is that I'm using the precompiled 
Win32 SQLite DLL from the SQLite website (sqlitedll.zip). I 
wanted to recompile it but there are no build instructions for 
MSVC *sigh*.

Is there any way to test the integrity of an SQLite database? This 
is giving me the jeebies.

Apparently, I can't attach files in Sourceforge. So, I'm going to 
send you two files by e-mail. There are: -
  1. db.zip: The sqlite database used.
  2. dbexport.zip: The exported version of db.zip.

Logged In: YES 
user_id=69293

There was a bug in SQLite associated with empty sets like "()".
That bug has been fixed and entered into the CVS server.  It
will appear in the next release (2.7.3).

See http://cvs.hwaci.com:2080/sqlite/tktview?tn=185

Logged In: YES 
user_id=638767

It works! Thanks!

Logged In: YES 
user_id=6405

I've put some extra code into the sqlite backend to handle this case too.