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

Bug#673596: libc6: FTBFS on wheezy/sid amd64 (test suite failures)



On 22/05/12 07:09, Aurelien Jarno wrote:
On Tue, May 22, 2012 at 02:01:44AM +0100, Philip Ashmore wrote:
On 20/05/12 20:22, Aurelien Jarno wrote:
tag 673596 + unreproducible
thanks

On Sun, May 20, 2012 at 04:01:10AM +0100, Philip Ashmore wrote:
On 20/05/12 03:02, Jonathan Nieder wrote:
Hi Philip,

Philip Ashmore wrote:

annexc.out, Error 1 (ignored)
tst-eintr1.out, Error 1
tst-writev.out, Error 1
***************
Encountered regressions that don't match expected failures:
tst-eintr1.out, Error 1

What does the tst-eintr1.out file say?

Curious,
Jonathan

.tf1: pthread_create failed: Resource temporarily unavailable
tf1: pthread_create failed: Resource temporarily unavailable

That dot before "tf1" is repeated 3734 times.


I am unable to reproduce this bug on my machines, and it really looks
like an environment specific bug. I am therefore not planning to work on
this bug. If someone is able to reproduce it, please work on it.
Hi there.
I created VMware virtual machines based on the following ISOs.
    debian-6.0.5-amd64-netinst.iso
    debian-wheezy-DI-a1-amd64-netinst.iso

I wanted to use qemu, but I couldn't get kvm to work so it was too slow.

I ran through the eglibc build on both of them.
The 6.0.5 installation built eglibc-2.11.3 successfully.

Which is kind of expected, given we don't check for testsuite results on
stable version of the libc. This is for example to avoid breaking the
stable and security updates in case an incompatible new version of the
kernel in installed two years after.

The wheezy installation failed to build eglibc-2.13-32 with the following errors<<EOF

make[2]: Target `check' not remade because of errors.
make[2]: Leaving directory `/home/contact/eglibc-2.13'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/contact/eglibc-2.13/build-tree/amd64-libc'
#
# Testsuite failures, someone should be working towards
# fixing these! They are listed here for the purpose of
# regression testing during builds.
# Format:<Failed test>, Error<Make error code>   [(ignored)]
#
annexc.out, Error 1 (ignored)
tst-cpuclock2.out, Error 1
tst-eintr1.out, Error 1
tst-writev.out, Error 1
***************
Encountered regressions that don't match expected failures:
tst-eintr1.out, Error 1
make: *** [/home/contact/eglibc-2.13/stamp-dir/check_libc] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1350:
dpkg-buildpackage -rfakeroot -D -us -uc -b -j4 failed
EOF

I suspended the VM part way through which may account for the cpuclock2 error.

Anyway it's not the cause of the failure here, we have disabled it
because the test fails often on machines with variable CPU frequency.

Can you tell me what your kernel version is, hardware etc?

I have not been able to reproduce the issue on:
- A Core i5 M560, running a 3.2.0-2-amd64 kernel
- A core i5 2500, running a 3.2.0-2-amd64 kernel
- An 4 x AMD Opteron 6134, running a 2.6.32-5-amd64 kernel
- A KVM instance on a Core i7 2600k, running a 2.6.32-5-amd64 kernel

Do you have KDE4 installed?

On some of the machines yes. Have you experienced it makes a difference?
I really doubt.

For squeeze, the default root fs is ext3, for wheezy it's ext4.

I really doubt this makes a difference.

The problem is clearly that at some point the system is not able to
create new threads anymore due to resources limits. In your case it's
likely due to the fact you are machine is a virtual VMWare machine.
Have you tried to run the build on a real hardware?
Yep.
When I reported the bug.
I used VMware to build installations that are "pure" - no third party
repos, using defaults except for KDE4 which I dislike less than Gnome.

Essentially I've gotten failures on two hardware types - one real, the
other virtual, but running on the same machine.

Given that I've had no crashes otherwise, it's hard to conceive that the
"problem"only surfaces when building eglibc.

Are there any hardware test suites I can run to eliminate this as the
potential cause of these failures?

Regards,
Philip




Reply to: