Open Stack

On Tue, Jan 27, 2015, at 09:13 AM, Julien Danjou wrote:
> On Tue, Jan 27 2015, Doug Hellmann wrote:
> 
> > The infra team has been working hard to update our Python 3 testing for all
> > projects to run on 3.4 instead of 3.3. Two of the last projects to be able to
> > shift are oslo.messaging and oslo.rootwrap. The test suites for both projects
> > trigger a segfault bug in the 3.4 interpreter as it is shipped on Ubuntu
> > Trusty. The fix for the segfault is already available upstream, and the team at
> > Canonical is working on packaging a new release, but our schedules are out of
> > sync. Maintaining a separate image and pool of testing nodes for 3.3 testing of
> > just these two projects is going to be a bit of a burden, and so the infra team
> > has asked if we’re willing to turn off the 3.3 jobs for the two projects,
> > leaving us without 3.x testing in the gate until the 3.4 interpreter on Trusty
> > is updated.
> 
> Isn't there any way to have an ugly work-around in those libs that
> wouldn't trigger the Python 3.4 segfault or at least disable the
> responsible tests until Python 3.4 gets fixed?
> 
So the issue is that the garbage collector segfaults on null objects in
the to be garbage collected list. Which means that by the time garbage
collection breaks you don't have the info you need to know what
references lead to the segfault. I spent a bit of time in gdb debugging
this and narrowed it down enough to realize what the bug was and find it
was fixed in later python releases but didn't have the time to sort out
how to figure out specifically which references in oslo.messaging caused
the garbage collector to fall over.

For oslo.rootwrap it affected any tests that ran with logging due to the
way rootwrap does logging iirc.

Clark