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.

classification
Title: Segfault in sqlite3
Type: crash Stage: resolved
Components: Versions: Python 2.7
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: intchanter, ned.deily
Priority: normal Keywords:

Created on 2017-01-10 19:45 by intchanter, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python_2017-01-09-152821_C02PWM27G8WN.crash intchanter, 2017-01-10 19:45 Mac OS crash log
Messages (4)
msg285150 - (view) Author: Daniel Fackrell (intchanter) Date: 2017-01-10 19:45
This crash occurs while running some unittests in one of our Django apps.

It duplicates on all three versions I've tried (2.7.10, 2.7.12, and 2.7.13). I don't have a Python3-capable code to test against at present.

It fails on my Mac OS system, and we can't duplicate the issue on an Ubuntu system. There's one particular test that consistently triggers it, but only if most of the other tests for the same file run first.

I've attached the .crash file (with Python 2.7.13), and included pip freeze and uname -a output below. Please let me know if I can provide more info to help with debugging this.

$ uname -a
Darwin c02pwm27g8wn.corp.verisys.com 15.6.0 Darwin Kernel Version 15.6.0: Wed Nov  2 20:30:56 PDT 2016; root:xnu-3248.60.11.1.2~2/RELEASE_X86_64 x86_64

$ pip freeze
coverage==4.3.1
Django==1.8.17
django-nose==1.4.4
funcsigs==1.0.2
lxml==3.4.4
mock==2.0.0
model-mommy==1.3.1
MySQL-python==1.2.5
nose==1.3.7
pbr==1.10.0
pycrypto==2.6.1
pytz==2016.10
requests==2.12.4
six==1.10.0
suds==0.4
msg285153 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2017-01-10 20:25
Thanks for the report.  From a quick look at the macOS crash report, I'm guessing you are running with the Apple-supplied system Python 2.7 but with a virtualenv.  In any case, the Apple-supplied libsqlite3 is in use and there are previously reported problems using it with multiple threads, possibly multiple processes, accessing the same database file; see for example Issue27126.  Suggest you try using a Python instance that is linked with its own version of a current libsqlite3, rather than with the system one: Pythons installed from current python.org macOS installers, from Macports, or (probably) Homebrew should all fit the bill and see if the problems go away.
msg285579 - (view) Author: Daniel Fackrell (intchanter) Date: 2017-01-16 18:26
I was using versions of python from pyenv, but they may have been using the system version of sqlite3. I recreated the virtualenv using python 2.7.13 installed with Brew, and it doesn't crash.

sqlite3.sqlite_version went from 3.8.10.2 to 3.16.2, which seems like a rather large jump.

Thank you for your assistance on this! I'm still trying to find a good way to get pyenv to recognize and use the newer library, but I can handle that outside of this ticket unless you have some quick tips already handy for that.
msg285580 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2017-01-16 18:38
> I'm still trying to find a good way to get pyenv to recognize and use the newer library

Thanks for confirming that the problem was due to the version of sqlite3 in use.  If you haven't already, suggest you open an issue on the pyenv project tracker or ask elsewhere.  Good luck!

https://github.com/yyuu/pyenv
History
Date User Action Args
2022-04-11 14:58:41adminsetgithub: 73416
2017-01-16 18:38:15ned.deilysetstatus: open -> closed

messages: + msg285580
stage: resolved
2017-01-16 18:26:08intchantersetstatus: pending -> open

messages: + msg285579
2017-01-10 20:25:59ned.deilysetstatus: open -> pending

nosy: + ned.deily
messages: + msg285153

resolution: third party
2017-01-10 19:45:11intchantercreate