I'm the APSW author. You do not need SQLite installed - APSW's setup can fetch the current SQLite and use it privately not affecting the rest of the system.
An easier way of testing is:
python3 setup.py fetch --sqlite --version 3.7.14 build_ext --inplace --force
Create test.sql with these contents
.output output_file
.mode csv
select 3, '4';
Then run:
env PYTHONPATH=. python3 tools/shell.py
.read test.sql
The actual code where the problem happens does the following:
- Create a StringIO
- Initialize csv.writer using the StringIO
- Write one row with two values (this is when the crash happens in Python 3.3 on the first write)
- Copy the current contents of the StringIO to the actual output file changing encoding as needed
- Truncate StringIO and seek back to offset zero ready for the next line
The relevant code is in tools/shell.py in the output_csv function. Writing just that sequence of code above doesn't result in the assertion. valgrind doesn't show any problems either (using pydebug, without pymalloc and all the freelists set to zero).
A stack trace is here: https://code.google.com/p/apsw/issues/detail?id=132#c4
If not using a debug/nopymalloc build then you get a crash happening later.

In general APSW does not look ready for the Python 3.3 Unicode
implementation. Example: src/statementcache.c:217
Py_UNICODE *out;
PyObject *res=PyUnicode_FromUnicode(NULL, size);
Python 3.3 docs:
"If the buffer is NULL, PyUnicode_READY() must be called once the string content has been filled before using any of the access macros such as PyUnicode_KIND()."
The abort() in the traceback occurs precisely because PyUnicode_READY()
hasn't been called, so I'm closing this as invalid.

How do you get values to write? Most likely, the problem has nothing to do with csv module, but written values are broken. Possible error in sqlite module, or in any conversion function, or in you APSW C-code. Can you dump this values before sending to writerow?

My understanding was that code that calls the public APIs should continue to work. Is this a new requirement in 3.3, or is it that it has always been a requirement but code could get away without the ready before?
Either way we need to add an note to the Porting section of What's New.

R. David Murray <report@bugs.python.org> wrote:
> My understanding was that code that calls the public APIs should continue to
> work. Is this a new requirement in 3.3, or is it that it has always been a
> requirement but code could get away without the ready before?
It's a new requirement.
> Either way we need to add an note to the Porting section of What's New.
Good point. The main hint I find is here:
http://docs.python.org/py3k/whatsnew/3.3.html#deprecated-functions-and-types-of-the-c-api
But you have to click through to:
http://docs.python.org/py3k/c-api/unicode.html#PyUnicode_FromUnicodePEP 393 on the other hand has this paragraph:
"Extension modules using the legacy API may inadvertently call PyUnicode_READY,
by calling some API that requires that the object is ready, and then continue
accessing the (now invalid) Py_UNICODE pointer. Such code will break with this
PEP. The code was already flawed in 3.2, as there is was no explicit guarantee
that the PyUnicode_AS_UNICODE result would stay valid after an API call (due
to the possibility of string resizing). Modules that face this issue need to
re-fetch the Py_UNICODE pointer after API calls; doing so will continue to
work correctly in earlier Python versions."

"In general APSW does not look ready for the Python 3.3 Unicode implementation."
I bet that most Python modules implemented in C use the "legacy" (old) Unicode API (Py_UNICODE*). Python 3.3 must call PyUnicode_READY() everywhere (where the new API is used to get attribute of a string, ex: PyUnicode_GET_LENGTH).

(APSW author here). I haven't ported to the new Python 3.3 Unicode handling yet but it is on my todo list. The PEPs and doc said the C API would remain backwards compatible. The APSW code supports Python 2.3 onwards.
SQLite APIs support both UTF-8 and UTF-16. Py_UNICODE_SIZE is used to select between two code paths - if 2 then the UTF-16 APIs are used and if 4 then a UTF-8 conversion is made and those APIs used. Python 3.3 makes Py_UNICODE_SIZE meaningless and will be quite a bit of work to integrate as a third branch.
It should be noted that at no point is there any dependence of the underlying bytes/pointer living a long time. They are only used at the point which data needs to be transferred between Python types and SQLite APIs (both ways) and not held outside of that period.

> The PEPs and doc said the C API would remain backwards compatible.
Roger: Yes, you don't need to change anything. I was misled by the
PyUnicode_AsUnicode() docs, thinking that the responsibility to call
PyUnicode_READY() also applies if the generated Unicode Object is
passed to the C-API.