You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found that the sqlite3 function executemany module crashes when passed in a generator that it iself is executing a query. It looks like this confuses the statement cache, and causes it to get cleared inappropriately in this case.
I've attached a file that exhibits the problem, which results in this stack trace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028
pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367
367 self->in_use = 1;
(gdb) bt
#0 pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367 #1 0x000000010067e125 in _pysqlite_query_execute (self=0x100568880, multiple=1, args=<value temporarily unavailable, due to optimizations>) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/cursor.c:625 #2 0x00000001000af6a2 in PyEval_EvalFrameEx (f=0x1003579f0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:3874 #3 0x00000001000b000a in PyEval_EvalCodeEx (_co=0x1004977a0, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3310 #4 0x00000001000b031f in PyEval_EvalCode (co=<value temporarily unavailable, due to optimizations>, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:760 #5 0x00000001000d71eb in run_mod [inlined] () at /Users/Shared/erickt/Projects/py3k/Python/pythonrun.c:1759 #6 0x00000001000d71eb in PyRun_FileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", start=<value temporarily unavailable, due to optimizations>, globals=0x100325220, locals=0x100325220, closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1716 #7 0x00000001000d74b9 in PyRun_SimpleFileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1241 #8 0x00000001000ebe13 in Py_Main (argc=4832928, argv=<value temporarily unavailable, due to optimizations>) at Modules/main.c:297 #9 0x0000000100000abf in main (argc=2, argv=0x7fff5fbff090) at ./Modules/python.c:59
Activity
ErickTryzelaar commentedon Jan 3, 2011
I found that the sqlite3 function executemany module crashes when passed in a generator that it iself is executing a query. It looks like this confuses the statement cache, and causes it to get cleared inappropriately in this case.
I've attached a file that exhibits the problem, which results in this stack trace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028
pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367
367 self->in_use = 1;
(gdb) bt
#0 pysqlite_statement_mark_dirty (self=0x0) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/statement.c:367
#1 0x000000010067e125 in _pysqlite_query_execute (self=0x100568880, multiple=1, args=<value temporarily unavailable, due to optimizations>) at /Users/Shared/erickt/Projects/py3k/Modules/_sqlite/cursor.c:625
#2 0x00000001000af6a2 in PyEval_EvalFrameEx (f=0x1003579f0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:3874
#3 0x00000001000b000a in PyEval_EvalCodeEx (_co=0x1004977a0, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3310
#4 0x00000001000b031f in PyEval_EvalCode (co=<value temporarily unavailable, due to optimizations>, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:760
#5 0x00000001000d71eb in run_mod [inlined] () at /Users/Shared/erickt/Projects/py3k/Python/pythonrun.c:1759
#6 0x00000001000d71eb in PyRun_FileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", start=<value temporarily unavailable, due to optimizations>, globals=0x100325220, locals=0x100325220, closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1716
#7 0x00000001000d74b9 in PyRun_SimpleFileExFlags (fp=0x7fff703f6f40, filename=0x1005c9190 "/Users/erickt/sqlite-crash.py", closeit=1, flags=0x7fff5fbfef90) at Python/pythonrun.c:1241
#8 0x00000001000ebe13 in Py_Main (argc=4832928, argv=<value temporarily unavailable, due to optimizations>) at Modules/main.c:297
#9 0x0000000100000abf in main (argc=2, argv=0x7fff5fbff090) at ./Modules/python.c:59
python-dev commentedon May 9, 2011
New changeset c6523d6faef4 by Gerhard Haering in branch 'default':
bpo-10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/c6523d6faef4
python-dev commentedon May 9, 2011
New changeset 2fdabf0dc8f7 by Victor Stinner in branch 'default':
Issue bpo-10811: Use TestCase.assertRaises() in the new test
http://hg.python.org/cpython/rev/2fdabf0dc8f7
ezio-melotti commentedon Nov 25, 2011
Can this be closed?
akheron commentedon Feb 3, 2012
It seems to me that the fix still needs to be backported to 3.2 and 2.7.
python-dev commentedon Feb 6, 2012
New changeset 631e99961c5f by Petri Lehtinen in branch '2.7':
Issue bpo-10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/631e99961c5f
New changeset d51ceef4b62f by Petri Lehtinen in branch '3.2':
Issue bpo-10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/d51ceef4b62f
akheron commentedon Feb 6, 2012
It's now fixed in all branches. Thanks for reporting!