This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author barry
Recipients Arfrever, alexandre.vassalotti, barry, josh.r, nadeem.vawda, pitrou, python-dev, serhiy.storchaka
Date 2016-01-06.21:52:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1452117144.62.0.138260197144.issue22995@psf.upfronthosting.co.za>
In-reply-to
Content
I'm reopening this issue because we're starting to see a bunch of regressions in Debian and Ubuntu we think is caused by the changes here.  We've definitely started seeing them with 3.5.1, where packages that use Cython built just fine in 3.5.0 but now fail with TypeError in 3.5.1.  I haven't been able to completely debug the problem yet, but here's what I know.

Here's a build log for s3ql that shows the failure: http://paste.debian.net/361351/

Here's a bug report showing a build failure for kivy, leading to the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810139

Nothing immediately jumps out at me as problematic with the NameAssignment class, which afaict is defined in Cython/Compiler/FlowControl.py as thus:

class NameAssignment(object):
    def __init__(self, lhs, rhs, entry):
        if lhs.cf_state is None:
            lhs.cf_state = set()
        self.lhs = lhs
        self.rhs = rhs
        self.entry = entry
        self.pos = lhs.pos
        self.refs = set()
        self.is_arg = False
        self.is_deletion = False
        self.inferred_type = None

    def __repr__(self):
        return '%s(entry=%r)' % (self.__class__.__name__, self.entry)

    def infer_type(self):
        self.inferred_type = self.rhs.infer_type(self.entry.scope)
        return self.inferred_type

    def type_dependencies(self):
        return self.rhs.type_dependencies(self.entry.scope)

    @property
    def type(self):
        if not self.entry.type.is_unspecified:
            return self.entry.type
        return self.inferred_type


I suppose it's possible that something outside the class is poking an unpicklable attribute into the instance, but wouldn't that show up as a pickling error of a different class?  

The TypeError is being raised in deepcopy() in copy.py, where it is getting x's __reduce_ex__ and then calling reductor(4) (see ~line 174).  If you catch the TypeError on that line and set a breakpoint, then call `copy(x)` you see the TypeError.

I tried calling copy.deepcopy() on all the attributes of the NameAssignment instance I could find, and they all copied just fine.

I'm going to try to set up a gdb to figure out exactly which of the new picklability tests is failing, but I definitely think we have a regression here.  I suppose it's also possible that it's a legitimate bug in Cython, but then how did it ever work before?
History
Date User Action Args
2016-01-06 21:52:24barrysetrecipients: + barry, pitrou, alexandre.vassalotti, nadeem.vawda, Arfrever, python-dev, serhiy.storchaka, josh.r
2016-01-06 21:52:24barrysetmessageid: <1452117144.62.0.138260197144.issue22995@psf.upfronthosting.co.za>
2016-01-06 21:52:24barrylinkissue22995 messages
2016-01-06 21:52:24barrycreate