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
{{ message }}
Repository navigation
_elementtree.TreeBuilder broken with a non-C-deriving element_factory #60293
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)
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.
skrah commented on Sep 30, 2012
skrahmannequin
Mannequin
More actions
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.
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()
elibendersky commented on Sep 30, 2012
elibenderskymannequin
Mannequin
More actions
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.
skrah commented on Sep 30, 2012
skrahmannequin
Mannequin
More actions
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.
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).
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.
skrah commented on Oct 2, 2012
skrahmannequin
Mannequin
More actions
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:
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
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.
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.
elibendersky commented on Oct 4, 2012
elibenderskymannequin
Mannequin
More actions
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.
Activity
tiran commentedon Sep 30, 2012
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.
[1] http://www.owlfish.com/software/simpleTAL/downloads/SimpleTAL-5.1.tar.gz
tiran commentedon Sep 30, 2012
The issue could be related to bpo-14007.
skrah commentedon Sep 30, 2012
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()?
tiran commentedon Sep 30, 2012
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.
skrah commentedon Sep 30, 2012
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.
tiran commentedon Sep 30, 2012
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()
elibendersky commentedon Sep 30, 2012
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.
skrah commentedon Sep 30, 2012
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.
birkenfeld commentedon Oct 1, 2012
Let's make sure this gets into 3.3.1.
pitrou commentedon Oct 1, 2012
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 :)
pitrou commentedon Oct 1, 2012
More assorted celementtree cleanups.
2 remaining items
pitrou commentedon Oct 1, 2012
Example of this is the following code in treebuilder_handle_start:
(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).
pitrou commentedon Oct 1, 2012
I'll still commit my cleanup patch in the meantime :-)
python-dev commentedon Oct 1, 2012
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
elibendersky commentedon Oct 1, 2012
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.
skrah commentedon Oct 2, 2012
Nice find. -- The Python version does this:
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
pitrou commentedon Oct 2, 2012
Here is a patch. It still needs some tests.
[-]_elementtree causes segfault in GC[/-][+]_elementtree.TreeBuilder broken with a non-C-deriving element_factory[/+]pitrou commentedon Oct 2, 2012
Updated patch with tests.
python-dev commentedon Oct 4, 2012
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
elibendersky commentedon Oct 4, 2012
Antoine, Thanks!
You said :
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.
pitrou commentedon Oct 4, 2012
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.
elibendersky commentedon Oct 4, 2012
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.
mitya57 commentedon Nov 9, 2012
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).