Hi, On Friday 28 May 2010, Bruno Haible wrote: > Hi, > > > >> Chris Clayton wrote: > > >> > but make check hangs when > > >> > gnulib-tests/test-lock is run. The log showed that the hang occurred > > >> > somewhere after the > > >> > message "Starting test_rwlock" was output > > > > ... > > > > > The only thing I can think of is that glibc is a bit old at 2.7, > > > > Using glibc-2.7 with a new kernel is unusual indeed. > > But the kernel people try hard not to break backward compatibility, and > while glibc-2.7 is not as bleeding edge as linux 2.6.34, it is less than > 3 years old. > > You can easily reduce the size of test-lock.c so that only one of the four > tests is run. The next step will be to manually expand the macros from > gnulib's <lock.h>, so that you get 100% POSIX compliant source code. > With that, you could go to the glibc people and ask for help. > > But given that glibc-2.7 is old, you would need someone else to reproduce > it also with a newer glibc. And personally I would guess it's a breakage > in the new linux 2.6.34. But in order to isolate a bug in the multithread > system calls, you need help of a some super hacker like Ulrich Drepper or > Ingo Molnar. >
I built and installed glibc-2.11.1, this time against 2.6.33.4 kernel headers instead of the 2.6.26.x headers that were previously in /usr/src/linux. My idea was to just test the failing coreutils test application (test-lock), although, of course, a failure with this configuration may have been a false failure. Anyway. my system seems to be completely stable (although I do have the comfort of an archive of the old glibc-2.7-based system) and more importantly in the context of coreutils and gnulib, test-lock succeeds every time. I guess that could be a false success because all my apps are built against glibc-2.7 but running against glibc-2.11.1, but I've given my most frequently used applications a quite a good workout and everything seems to be working. On the face of it, the problem is in libpthread in glibc-2.7, especially as it went away when the coreutil test applications were built against libpth. Unless someone knows of a really good reason to do so, I'm not minded to chase this any longer. I have a workaround to build and test coreutils should I find that I need to revert to my glibc-2.7-based system, but for the time being at least, I think I'll stick with 2.11.1. Thanks for your help. > So, can you trim down the testcase to something that fails with glibc-2.11 > and submit that through the glibc bugzilla? > > Bruno -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller
