Summary: | =sys-apps/portage-2.2.7 segfaults in visit_decref at Modules/gcmodule.c:361 - 'str' object has no attribute 'cpv_split' in portage/versions.py, line 336 called from portage/versions.py, line 382 with both mydata and cpv set to 'sys-devel/automake-1.12' | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Justin Lecher (RETIRED) <jlec> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | kernel, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | abrt.log |
Description
Justin Lecher (RETIRED)
2013-11-22 11:32:25 UTC
Created attachment 363794 [details]
abrt.log
Full trace log
Is this reproducible? What segfaults here is python. Hardware problems could easily cause this. It did so 4 times in a row. But now it isn't doing it anymore. Any news from your side? Otherwise I don't see anything we can do here. (In reply to Sebastian Luther (few) from comment #4) > Any news from your side? Otherwise I don't see anything we can do here. Probably this is related to the sandbox problem with linux-3.12* The output is mangled with the backtrace, noteworthy is the summary ($$$): > :#0 visit_decref (op=<unknown at remote 0x80>, data=0x0) at /var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Modules/gcmodule.c:361 > $$$ :Python Exception <type 'exceptions.TypeError'> object of type 'FakeRepr' has no len(): $$$ > :#1 0x00002b10febd42f8 in dict_traverse (op=, visit=0x2b10fecbcf40 <visit_decref>, arg=0x0) at /var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Objects/dictobject.c:2402 If we look further we can see that Python gives us the values in the parameters, which learns us more: > 'str' object has no attribute 'cpv_split' So, eh, which 'str' object? > Frame 0x13bd220, for file /usr/lib64/portage/pym/portage/versions.py, line 336, in catpkgsplit (mydata='sys-devel/automake-1.12', silent=1, eapi=None) Ah! > def catpkgsplit(mydata, silent=1, eapi=None): > ... > return mydata.cpv_split Bummer. Hmm, so, 'mydata' is a string; huh, what calls it then? > Frame 0x13bae60, for file /usr/lib64/portage/pym/portage/versions.py, line 382, in __init__ (self=<_pkg_str at remote 0x2b1104a353d0>, cpv='sys-devel/automake-1.12', metadata=None, settings=None, eapi=None, repo=None, slot=None) Note that the 'cpv' parameter appears to be fine. If we look a bit up, we get to see the cpv parameter to the catpkgsplit call getting initialized this way: > if not isinstance(cpv, _unicode): > # Avoid TypeError from _unicode.__init__ with PyPy. > cpv = _unicode_decode(cpv) > _unicode.__init__(cpv) So, appears we have something related to Unicode failing. Seems that something in this _unicode functionality might change the object into a string. I'm not convinced that this is caused by the kernel, but regardless; we'll follow the bug to follow along what's going on. I suggest checking whether this is reproducible on a different version of Python as well as trying a non-3.12 kernel. Alternatively you can try to apply the commit that patches it (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ede4cebce16f5643c61aedd6d88d9070a1d23a68) so you don't have to build the whole kernel again. (In reply to Justin Lecher from comment #3) > It did so 4 times in a row. But now it isn't doing it anymore. Interesting, sounds like an odd random bug in either Python or the kernel... Hmm, if you can't consistently reproduce it, that might complicate things. :/ http://bugs.python.org/issue17951 and http://bugs.python.org/msg188888 appear to tell me that the summary I first caught between the output is a false positive which is a result of gdb debug, I'll update the summary with the Python errors. Oh look, something very similar reported upstream by Arfrever. \o/ Not sure if this is the exact same, but it is very likely; can you try 3.2? > #gentoo-python [Arfrever] | CPython bug 16089 is fixed in CPython >=3.3.1.
(In reply to Tom Wijsman (TomWij) from comment #8) > Not sure if this is the exact same, but it is very likely; can you try 3.2? It is not reproducible at the moment. And I never saw this with py3.2. |