Skip to content

sqlite segfault with generators #55020

Closed
Closed

Description

@ErickTryzelaar
BPO 10811
Nosy @ezio-melotti, @akheron
Files
  • sqlite-crash.py
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2012-02-06.20:08:04.901>
    created_at = <Date 2011-01-03.01:33:45.489>
    labels = ['library', 'type-crash']
    title = 'sqlite segfault with generators'
    updated_at = <Date 2012-02-06.20:08:04.900>
    user = 'https://bugs.python.org/ErickTryzelaar'

    bugs.python.org fields:

    activity = <Date 2012-02-06.20:08:04.900>
    actor = 'petri.lehtinen'
    assignee = 'ghaering'
    closed = True
    closed_date = <Date 2012-02-06.20:08:04.901>
    closer = 'petri.lehtinen'
    components = ['Library (Lib)']
    creation = <Date 2011-01-03.01:33:45.489>
    creator = 'Erick.Tryzelaar'
    dependencies = []
    files = ['20238']
    hgrepos = []
    issue_num = 10811
    keywords = []
    message_count = 7.0
    messages = ['125148', '135574', '135582', '148302', '152499', '152765', '152766']
    nosy_count = 5.0
    nosy_names = ['ghaering', 'ezio.melotti', 'Erick.Tryzelaar', 'python-dev', 'petri.lehtinen']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue10811'
    versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

    Activity

    1. ErickTryzelaar commented on Jan 3, 2011

      ErickTryzelaarmannequin
      MannequinAuthor

      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

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Jan 3, 2011
    3. python-dev commented on May 9, 2011

      python-devmannequin
      Mannequin

      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

    4. python-dev commented on May 9, 2011

      python-devmannequin
      Mannequin

      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

    5. ezio-melotti commented on Nov 25, 2011

      @ezio-melotti
      Member

      Can this be closed?

    6. akheron commented on Feb 3, 2012

      @akheron
      Member

      It seems to me that the fix still needs to be backported to 3.2 and 2.7.

    7. python-dev commented on Feb 6, 2012

      python-devmannequin
      Mannequin

      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

    8. akheron commented on Feb 6, 2012

      @akheron
      Member

      It's now fixed in all branches. Thanks for reporting!

    9. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      stdlibStandard Library Python modules in the Lib/ directorytype-crashA hard crash of the interpreter, possibly with a core dump

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions