[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problems with mips builds on ball (potential mass give-back)

On 2012-07-14 23:56:02 (+0100), Simon McVittie <smcv@debian.org> wrote:
> (Re-sending to a wider audience than mips@b.d.o, with more information and
> a somewhat complete list of give-backs.)
> ball.debian.org seems to be rather unhappy. My recent dbus upload failed
> with this in the log:
> ../../dbus/dbus-transport.c: In function
> '_dbus_transport_get_is_authenticated':
> ../../dbus/dbus-transport.c:788:1: internal compiler error: Segmentation
> fault
> [... log noise from a parallel compilation omitted ...]
> The bug is not reproducible, so it is likely a hardware or OS problem.
> I assume that last line means that recent gcc automatically retries
> compilations that failed with a segfault, to see whether they work the
> second time?
> It's not the only package in a similar situation: when I picked some examples
> at random, nipy's tests segfaulted, and nmap and gamera
> suffered an unreproducible compiler segfault similar to dbus. Each of
> those packages built successfully on the other architectures.
> Ben Hutchings reported a similar problem on kernel backport builds
> <https://lists.debian.org/debian-kernel/2012/07/msg00105.html>.
> I've attempted to provide a list of affected packages in sid (by looking at
> buildd.debian.org, I know nothing about most of these packages). See below
> for that; it's a list of gb commands which can be given when ball has been
> repaired or removed from service. I haven't done this for any other suites
> so far, but ball appears to build at least squeeze-backports too.
> The list does not include builds on ball which failed for similar reasons
> on other architectures, on the assumption that those are more likely to be
> package bugs.
> This could be rather unfortunate for packages' testing migration, which
> is why I've cc'd the release team.

I have been looking at the kernel logs, but I haven't noticed any messages
hinting to a kernel problem. It doesn't help that the log is filled with:

[4749162.188000] lvremove: sending ioctl 20001261 to a partition!


[4749178.956000] lvcreate: sending ioctl 20001261 to a partition!

Ofcourse a broken RAM chip can't be ruled out. I don't think we have ECC memory
on ball.



Reply to: