Le 23/05/2012 17:26, Philip Ashmore a écrit : > On 05/23/2012 04:18 PM, Jonathan Nieder wrote: >> Jonathan Nieder wrote: >> >>> Do you have access to another machine you could try to reproduce the >>> problem on? >> >> Actually, before then: could you please run the test I outlined before? >> >> That is: >> >> 1. Find tst-eintr1. It should be somewhere like >> build-tree/amd64-libc/nptl/tst-eintr1 >> >> 2. Run it. (Like this: >> >> $ ldd build-tree/amd64-libc/nptl/tst-eintr1 >> $ build-tree/amd64-libc/nptl/tst-eintr1 >> >> ) >> >> Some variations on the theme would be to try the 32-bit version, too, >> and to try it with LD_LIBRARY_PATH set to use libpthread from >> build-tree/amd64-libc/nptl, but those can come later. >> >> Jonathan > ...and here they are<<EOF > $ ldd build-tree/amd64-libc/nptl/tst-eintr1 > linux-vdso.so.1 => (0x00007fff481ff000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007f6577c99000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6577912000) > /lib64/ld-linux-x86-64.so.2 (0x00007f6577ecd000) > contact@debian:~/eglibc-2.13$ build-tree/amd64-libc/nptl/tst-eintr1 > .................................................................................................................................................................................tf1: > pthread_create failed: Resource temporarily unavailable > .Expected signal 'Alarm clock' from child, got none > EOF > > If it helps I just ran the same VM in Ubuntu - same results inside the VM. >
For this kind of bug, i would clearly not trust any test done in a VM, as it can be clearly triggered by a bug/limitation of the virtualization system. -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
