This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rogerbinns
Recipients Arfrever, pitrou, rogerbinns
Date 2012-10-05.20:20:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349468454.23.0.720444025123.issue16145@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-10-05 20:20:54rogerbinnssetrecipients: + rogerbinns, pitrou, Arfrever
2012-10-05 20:20:54rogerbinnssetmessageid: <1349468454.23.0.720444025123.issue16145@psf.upfronthosting.co.za>
2012-10-05 20:20:54rogerbinnslinkissue16145 messages
2012-10-05 20:20:53rogerbinnscreate