Ned Deily added the comment:
I agree with Richard's comments. The crash appears to be a result of an
unsupported usage of SQLite and one that Python can't really protect you from.
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
_
Richard Oudkerk added the comment:
Adding the line
features[0][0]
to the end of main() produces a segfault for me on Linux.
The FAQ for sqlite3 says that
Under Unix, you should not carry an open SQLite database across a
fork() system call into the child process. Problems will res
Timothy O'Keefe added the comment:
Could you change the dummy function to do something other than simply return
the row? For example:
#!/usr/bin/env python
import sqlite3
import multiprocessing as mp
def main():
## --- create a database
conn = sqlite3.connect(':memory:')
conn.row_
Ned Deily added the comment:
What platform are you running on? Please run the following script in the same
environment as you get the segfault and report the results.
#!/usr/bin/env python
import multiprocessing
import platform
import sqlite3
import sys
print(sys.version)
print(sqlite3.versio
New submission from Timothy O'Keefe:
If you run this code, you will get a segfault. If you a) remove the row factory
from the following code or b) use the standard library map() instead of
multiprocessing.Pool.map, then the code does not crash.
#!/usr/bin/env python
import sqlite3
import mult
