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.