Skip to content

_elementtree.TreeBuilder broken with a non-C-deriving element_factory #60293

Closed

Description

@tiran
BPO 16089
Nosy @birkenfeld, @pitrou, @larryhastings, @tiran, @ezio-melotti, @skrah, @florentx, @mitya57
Files
  • issue16089-pseudo-fix.diff
  • ctree.patch
  • ctree2.patch
  • c_treebuilder.patch
  • c_treebuilder2.patch
  • 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-10-04.17:59:30.043>
    created_at = <Date 2012-09-30.02:07:42.686>
    labels = ['extension-modules', 'expert-XML', 'type-crash', 'release-blocker']
    title = '_elementtree.TreeBuilder broken with a non-C-deriving element_factory'
    updated_at = <Date 2012-11-09.13:51:34.072>
    user = 'https://github.com/tiran'

    bugs.python.org fields:

    activity = <Date 2012-11-09.13:51:34.072>
    actor = 'mitya57'
    assignee = 'none'
    closed = True
    closed_date = <Date 2012-10-04.17:59:30.043>
    closer = 'pitrou'
    components = ['Extension Modules', 'XML']
    creation = <Date 2012-09-30.02:07:42.686>
    creator = 'christian.heimes'
    dependencies = []
    files = ['27355', '27377', '27378', '27392', '27393']
    hgrepos = []
    issue_num = 16089
    keywords = ['patch', '3.3regression']
    message_count = 25.0
    messages = ['171603', '171605', '171619', '171625', '171629', '171630', '171642', '171644', '171738', '171739', '171742', '171746', '171748', '171749', '171751', '171752', '171753', '171778', '171829', '171831', '171981', '172009', '172014', '172019', '175235']
    nosy_count = 11.0
    nosy_names = ['georg.brandl', 'pitrou', 'larry', 'christian.heimes', 'ezio.melotti', 'Arfrever', 'eli.bendersky', 'skrah', 'flox', 'python-dev', 'mitya57']
    pr_nums = []
    priority = 'release blocker'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue16089'
    versions = ['Python 3.3', 'Python 3.4']

    Activity

    1. tiran commented on Sep 30, 2012

      @tiran
      MemberAuthor

      The issue was reported by Arfrever on #python-dev. The test suite of simpletal [1] was segfaulting with Python 3.3. It doesn't segfault without the _elementtree C extension.

      I'm able to reproduce the issue. It may take a couple of runs with a debug build of Python but eventually Python segfaults. So far segfaults occur inside a GC collection run. Benjamin suspects the issue is related to the new GC code in _elementtree.

      #0  visit_decref (op=<unknown at remote 0x7fea64fc8ca8>, data=0x0) at [Modules/gcmodule.c:361](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L361)
      #1  0x00000000004bccd5 in subtract_refs (containers=<optimized out>) at [Modules/gcmodule.c:386](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L386)
      #2  collect (generation=0, n_collected=0x7fffe3eedb70, n_uncollectable=0x7fffe3eedb78) at [Modules/gcmodule.c:891](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L891)
      #3  0x00000000004bd7e6 in collect_with_callback (generation=0) at [Modules/gcmodule.c:1048](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L1048)
      #4  collect_generations () at [Modules/gcmodule.c:1071](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L1071)
      #5  _PyObject_GC_Malloc (basicsize=<optimized out>) at [Modules/gcmodule.c:1580](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L1580)
      #6  0x00000000004bddcc in _PyObject_GC_Malloc (basicsize=<optimized out>) at [Modules/gcmodule.c:1567](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L1567)
      #7  _PyObject_GC_New (tp=0x8322a0) at [Modules/gcmodule.c:1590](https://github.com/python/cpython/blob/main/Modules/gcmodule.c#L1590)
      #8  0x0000000000548a3a in new_dict (values=0x0, keys=0xd02e60) at [Objects/dictobject.c:395](https://github.com/python/cpython/blob/main/Objects/dictobject.c#L395)
      #9  _PyDict_NewPresized (minused=<optimized out>) at [Objects/dictobject.c:1044](https://github.com/python/cpython/blob/main/Objects/dictobject.c#L1044)
      #10 0x000000000047a449 in PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at [Python/ceval.c:2245](https://github.com/python/cpython/blob/main/Python/ceval.c#L2245)
      #11 0x0000000000480b03 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7fffe3eede40, func=
          <function at remote 0x7fea653ff9e0>) at [Python/ceval.c:4150](https://github.com/python/cpython/blob/main/Python/ceval.c#L4150)
      

      [1] http://www.owlfish.com/software/simpleTAL/downloads/SimpleTAL-5.1.tar.gz

    2. added
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Sep 30, 2012
    3. tiran commented on Sep 30, 2012

      @tiran
      MemberAuthor

      The issue could be related to bpo-14007.

    4. skrah commented on Sep 30, 2012

      skrahmannequin
      Mannequin

      I can't reproduce this, so just a wild guess: Does the segfault still
      happen if you replace Py_XDECREF() with Py_CLEAR() in xmlparser_gc_clear()?

    5. tiran commented on Sep 30, 2012

      @tiran
      MemberAuthor

      No, it doesn't make a difference when I replace Py_XDECREF() with Py_CLEAR(). I've also replaced Py_(X)DECREF() in the other *_gc_clear() methods without success.

    6. skrah commented on Sep 30, 2012

      skrahmannequin
      Mannequin

      I'm now able to reproduce the issue with a non-debug build. As
      Christian says, using Py_CLEAR() does not help (though I wonder
      if it shouldn't be used anyway).

      Reverting part of 20b8f0ee3d64 "fixes" the segfault, see the
      attached diff. I don't know the code well enough to say if this
      is a valid possibility.

    7. tiran commented on Sep 30, 2012

      @tiran
      MemberAuthor

      I can confirm that Stefan's fix works. I ran the SimpleTAL test suite about hundred times in a loop without a segfault. But I don't understand why the change fixes the issue. Could the alteration just lead to another code path so the erroneous code isn't triggered?

      +1 for Py_CLEAR()

    8. elibendersky commented on Sep 30, 2012

      elibenderskymannequin
      Mannequin

      I'm currently somewhat "offline" for a while (cross-continental move), but I'll do my best to try to recreate my setup to test this problem and the proposed solution.

    9. skrah commented on Sep 30, 2012

      skrahmannequin
      Mannequin

      Do note that the patch is somewhat cargo-cult. I don't understand yet why
      it works; it may very well just silence the real problem.

    10. birkenfeld commented on Oct 1, 2012

      @birkenfeld
      Member

      Let's make sure this gets into 3.3.1.

    11. pitrou commented on Oct 1, 2012

      @pitrou
      Member

      Here is a collection of assorted small fixes for celementtree. There are probably other problems lurking (the coding style there is quite old).

      I cannot say anything about the crasher until there's a simple reproducer :)

    12. pitrou commented on Oct 1, 2012

      @pitrou
      Member

      More assorted celementtree cleanups.

    13. 2 remaining items

    14. pitrou commented on Oct 1, 2012

      @pitrou
      Member

      Example of this is the following code in treebuilder_handle_start:

          if (this != Py_None) {
              if (element_add_subelement((ElementObject*) this, node) < 0)
                  goto error;

      (note the overly optimistic cast)

      but this is really a pervasive problem, since in many places TreeBuilder is hard-wired to use a Element instance and nothing else (despite the element_factory).

      Note that simpleTAL cannot use the _elementtree.Element class, since their subclass also inherits from an exception subclass, and the object layouts conflict with each other (yeah, crappy design).

    15. pitrou commented on Oct 1, 2012

      @pitrou
      Member

      I'll still commit my cleanup patch in the meantime :-)

    16. python-dev commented on Oct 1, 2012

      python-devmannequin
      Mannequin

      New changeset f9224f23f473 by Antoine Pitrou in branch '3.3':
      Sanitize and modernize some of the _elementtree code (see issue bpo-16089).
      http://hg.python.org/cpython/rev/f9224f23f473

      New changeset 9fb0a8fc5d79 by Antoine Pitrou in branch 'default':
      Sanitize and modernize some of the _elementtree code (see issue bpo-16089).
      http://hg.python.org/cpython/rev/9fb0a8fc5d79

    17. elibendersky commented on Oct 1, 2012

      elibenderskymannequin
      Mannequin

      Thank you, Antoine, for looking into this. I wish I could participate in a meaningful way, but alas it will be days or weeks before I can recreate a suitable setup to get back hacking on Python.

    18. skrah commented on Oct 2, 2012

      skrahmannequin
      Mannequin

      Nice find. -- The Python version does this:

        _Element = _ElementInterface = Element

      So (naively) I would think the same should be done for the C version
      after importing Element.

      But then one runs into the object layouts conflict that you mentioned.

      On the other hand, in the original documentation direct use of
      _ElementInterface was discouraged:

      http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm#elementtree.ElementTree.\_ElementInterface-class

    19. pitrou commented on Oct 2, 2012

      @pitrou
      Member

      Here is a patch. It still needs some tests.

    20. changed the title [-]_elementtree causes segfault in GC[/-] [+]_elementtree.TreeBuilder broken with a non-C-deriving element_factory[/+] on Oct 2, 2012
    21. pitrou commented on Oct 2, 2012

      @pitrou
      Member

      Updated patch with tests.

    22. python-dev commented on Oct 4, 2012

      python-devmannequin
      Mannequin

      New changeset 7bd9626d8b4f by Antoine Pitrou in branch '3.3':
      Issue bpo-16089: Allow ElementTree.TreeBuilder to work again with a non-Element element_factory (fixes a regression in SimpleTAL).
      http://hg.python.org/cpython/rev/7bd9626d8b4f

      New changeset a8c044188731 by Antoine Pitrou in branch 'default':
      Issue bpo-16089: Allow ElementTree.TreeBuilder to work again with a non-Element element_factory (fixes a regression in SimpleTAL).
      http://hg.python.org/cpython/rev/a8c044188731

    23. elibendersky commented on Oct 4, 2012

      elibenderskymannequin
      Mannequin

      Antoine, Thanks!

      You said :

      the coding style there is quite old

      It would be great if you could elaborate, however briefly, if there's anything else besides your fixes that is old and should be modernized. I will admit to writing some of that code very recently, but that's mostly because I was trying to follow the existing coding style of the module, which was written a long time ago.

    24. pitrou commented on Oct 4, 2012

      @pitrou
      Member

      > the coding style there is quite old

      It would be great if you could elaborate, however briefly, if there's
      anything else besides your fixes that is old and should be modernized.
      I will admit to writing some of that code very recently, but that's
      mostly because I was trying to follow the existing coding style of the
      module, which was written a long time ago.

      I don't think that's you. I was talking about some of the cruft I
      removed (such as list_join() which was going through complicated hoops
      instead of calling PyUnicode_Join(), or manual filling of tuples instead
      of calling PyTuple_Pack()).

      There are still issues with internal functions stealing references and
      such.

    25. elibendersky commented on Oct 4, 2012

      elibenderskymannequin
      Mannequin

      Ah, OK. I was actually putting off refactorings in that code to after refactoring the test suite. The latter is in progress, it was paused by my vacation but I do plan to resume it eventually. Once the test suite is sufficiently humane (esp. moves off doctest to enable normal testing of multiple modules with the same set of tests) the refactoring should become easier.

    26. mitya57 commented on Nov 9, 2012

      mitya57mannequin
      Mannequin

      There are still some false-positive warnings caused by C code that affect docutils (see http://sourceforge.net/tracker/?func=detail&atid=422030&aid=3555164&group_id=38414).

      Look at this traceback for exmaple:

      http://paste.ubuntu.com/1345164/

      There, _ElementInterfaceWrapper is a subclass of etree._ElementInterface (http://repo.or.cz/w/docutils.git/blob/HEAD:/docutils/docutils/writers/odf_odt/__init__.py#l91).

    27. 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

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions