Re: TLS Fix for 6.1.1
DJ Lucas dj at linuxfromscratch.org writes: OMG sorry about that! I read about jhbuild a couple of weeks ago, can't remember what for. Stuck on the brain I guess...donno. Anyway *jhalfs* has proven to be a great tool! Thanks again. Er, wow. I thought you were joking or something. I just stumbled upon jhbuild: http://www.jamesh.id.au/software/jhbuild/ If I knew this existed, I might have named jhalfs differently. :/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote: I have not compared the testsuite results yet. I completely forgot about them, so I've got to rebuild without the patch again. The patched version tests are running now. Will report again tomorrow after work. [EMAIL PROTECTED] src]# grep Error glibc-build/glibc-check-log make[2]: [/usr/src/glibc-build/posix/annexc.out] Error 1 (ignored) [EMAIL PROTECTED] src]# grep Error glibc-build-patched/glibc-check-log make[2]: [/usr/src/glibc-build-patched/posix/annexc.out] Error 1 (ignored) [EMAIL PROTECTED] src]# All looks well. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote: [EMAIL PROTECTED] src]# grep Error glibc-build/glibc-check-log make[2]: [/usr/src/glibc-build/posix/annexc.out] Error 1 (ignored) [EMAIL PROTECTED] src]# grep Error glibc-build-patched/glibc-check-log make[2]: [/usr/src/glibc-build-patched/posix/annexc.out] Error 1 (ignored) [EMAIL PROTECTED] src]# All looks well. Thanks very much DJ. I'll get the patch in the book tonight and roll another pre-release. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Matthew Burgess wrote: DJ Lucas wrote: Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. I don't have time to test this myself, so I'm going to have to ask someone else to do a full 6.1.1-pre1 build without the patch and ensure the bug this fixes can be triggered. If so, I'll add the patch (assuming further testing shows the patch does indeed fix the problem). If it's too late for inclusion in the book, that would be bad for BLFS WRT OOo2 and possibly some issues with Xine, but at least please make mention of it in the eratta after it's been tested. Note that BLFS-6.1 assumes LFS-6.1 as a base, therefore I'd think that BLFS-6.1.1 (if there is such a release) will assume LFS-6.1.1. As such, I don't consider OOo2 to be an issue as it's not in an existing release of BLFS. Xine may be a different issue, though as I said, we've still got time to fix this if someone can volunteer the necessary time to verify the bug and the effectiveness of the patch. Okay...I originally built the system with the patch and then rebuilt glibc without (kill two birds with one stone). Here are the results with the unpatched glibc (as shown previously by Archaic in the blfs-support thread where this was discovered): [EMAIL PROTECTED] xbug]# /lib/libc.so.6 GNU C Library stable release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.3. Compiled on a Linux 2.6.11 system on 2005-11-22. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. [EMAIL PROTECTED] xbug]# unset LD_LIBRARY_PATH [EMAIL PROTECTED] xbug]# make clean rm -f lib[1234].so test_bug [EMAIL PROTECTED] xbug]# make gcc test_bug.c -o test_bug -ldl gcc -shared -o lib4.so lib4.c gcc -shared -o lib1.so lib1.c lib4.so gcc -shared -o lib3.so lib3.c gcc -shared -o lib2.so lib2.c lib3.so [EMAIL PROTECTED] xbug]# export LD_LIBRARY_PATH=.:/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib [EMAIL PROTECTED] xbug]# ./test_bug Success! [EMAIL PROTECTED] xbug]# rm lib3.so [EMAIL PROTECTED] xbug]# ./test_bug Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result = _rtld_local._dl_tls_max_dtv_idx' failed! [EMAIL PROTECTED] xbug]# unset LD_LIBRARY_PATH [EMAIL PROTECTED] xbug]# ./test_bug Success! [EMAIL PROTECTED] xbug]# I again rebuilt glibc with the patch. The results were as expected, problem appears to be solved. I have not compared the testsuite results yet. I completely forgot about them, so I've got to rebuild without the patch again. The patched version tests are running now. Will report again tomorrow after work. Here are the results of the test case with the patched glibc: [EMAIL PROTECTED] xbug]# /lib/libc.so.6 GNU C Library stable release version 2.3.4, by Roland McGrath et al. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.4.3. Compiled on a Linux 2.6.11 system on 2005-11-22. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. [EMAIL PROTECTED] xbug]# make clean rm -f lib[1234].so test_bug [EMAIL PROTECTED] xbug]# make gcc test_bug.c -o test_bug -ldl gcc -shared -o lib4.so lib4.c gcc -shared -o lib1.so lib1.c lib4.so gcc -shared -o lib3.so lib3.c gcc -shared -o lib2.so lib2.c lib3.so [EMAIL PROTECTED] xbug]# export LD_LIBRARY_PATH=.:/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib [EMAIL PROTECTED] xbug]# ./test_bug Success! [EMAIL PROTECTED] xbug]# rm lib3.so [EMAIL PROTECTED] xbug]# ./test_bug Success! [EMAIL PROTECTED] xbug]# unset LD_LIBRARY_PATH [EMAIL PROTECTED] xbug]# ./test_bug Success! [EMAIL PROTECTED] xbug]# -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Archaic wrote: On Sun, Nov 20, 2005 at 08:58:03PM +, DJ Lucas wrote: I think that the deciding factor should be that this is acknowledged and fixed upstream. OTOH, it looks like BLFS can work arround it if needs be with an LD_PRELOAD line...It might be a pain to find them, but it can be done I suppose. It should be noted that LD_PRELOAD can be used to accomplish some nasty things and as such certain security enhanced patches will not allow the use of this variable at all. IOW, it's probably not best to use LD_PRELOAD as a workaround when the problem is known and fixed upstream. I will be running some tests. However, being Thanksgiving week, my schedule is rather stressed. I don't know if I will make the weekend deadline. I used jhbuild for my first time last night so as to get at it quick. I like it! Ran overnight. I had to use patches for glibc (gcc4 related) in chapter 5. I should have it booting later tonightthen verifiy the error is there, and rebuild glibc again with the patch and verify it's gone. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote these words on 11/21/05 13:10 CST: [snip all] Hey dude! How about moving that clock up about 6 hours? :-) -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:12:00 up 58 days, 4:36, 3 users, load average: 1.73, 1.46, 0.79 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote: I used jhbuild for my first time last night so as to get at it quick. I jhbuild? jhalfs maybe? :) Either way, glad you liked it. We're always looking for suggestions, so feel free to send any to alfs-discuss. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Jeremy Huntwork wrote: DJ Lucas wrote: I used jhbuild for my first time last night so as to get at it quick. I jhbuild? jhalfs maybe? :) Either way, glad you liked it. We're always looking for suggestions, so feel free to send any to alfs-discuss. -- JH OMG sorry about that! I read about jhbuild a couple of weeks ago, can't remember what for. Stuck on the brain I guess...donno. Anyway *jhalfs* has proven to be a great tool! Thanks again. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Randy McMurchy wrote: Hey dude! How about moving that clock up about 6 hours? Sorry bout that. Chicago was a link to /etc/localtime (which was a link to itself (ID ten T error)). Thanks for bringing it to my attention. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
TLS Fix for 6.1.1
Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. The patch for 2.3.5 is also in patches. It's been running for about 10 hours on an establish system of around 4 months under moderate load. Unfortunately, I have no 2.3.4 systems left, so I'm unable to test, however, the bug reports on debian, gentoo, and redhat speak highly. :-) See the patch header for more details. 2.3.6 is said to be fixed which I've also not verified yet. If it's too late for inclusion in the book, that would be bad for BLFS WRT OOo2 and possibly some issues with Xine, but at least please make mention of it in the eratta after it's been tested. http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.3.4-tls_assert-1.patch -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote: Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. The patch for 2.3.5 is also in patches. It's been running for about 10 hours on an establish system of around 4 months under moderate load. Unfortunately, I have no 2.3.4 systems left, so I'm unable to test, however, the bug reports on debian, gentoo, and redhat speak highly. :-) See the patch header for more details. 2.3.6 is said to be fixed which I've also not verified yet. If it's too late for inclusion in the book, that would be bad for BLFS WRT OOo2 and possibly some issues with Xine, but at least please make mention of it in the eratta after it's been tested. http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.3.4-tls_assert-1.patch -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
DJ Lucas wrote: Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. I don't have time to test this myself, so I'm going to have to ask someone else to do a full 6.1.1-pre1 build without the patch and ensure the bug this fixes can be triggered. If so, I'll add the patch (assuming further testing shows the patch does indeed fix the problem). If it's too late for inclusion in the book, that would be bad for BLFS WRT OOo2 and possibly some issues with Xine, but at least please make mention of it in the eratta after it's been tested. Note that BLFS-6.1 assumes LFS-6.1 as a base, therefore I'd think that BLFS-6.1.1 (if there is such a release) will assume LFS-6.1.1. As such, I don't consider OOo2 to be an issue as it's not in an existing release of BLFS. Xine may be a different issue, though as I said, we've still got time to fix this if someone can volunteer the necessary time to verify the bug and the effectiveness of the patch. Thanks for highlighting the issue! Matt. PS: Apologies for the earlier blank reply - a little too hasty with the 'Send' key, I'm afraid :( -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, 20 Nov 2005, Matthew Burgess wrote: DJ Lucas wrote: Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. I don't have time to test this myself, so I'm going to have to ask someone else to do a full 6.1.1-pre1 build without the patch and ensure the bug this fixes can be triggered. If so, I'll add the patch (assuming further testing shows the patch does indeed fix the problem). Looking at the gentoo, debian, and blfs references, this seems to be triggered by (a) nvidia drivers, or (b) gnome (versions/items not specified), or (c) xmms (1.2.8? debian version) without libmikmod2, or (d) some OOo issue. From here, trying to trigger the bug looks like searching for a needle in a haystack. The xmms debian version is way before anything we'd use, so is this really an nvidia bug, or is the OOo problem not related to nvidia binary drivers? Personally, I've not seen any problems with xmms (1.2.10) or xine that sound like this bug, even on my 6.1 systems. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, Nov 20, 2005 at 09:56:28PM +, Ken Moffat wrote: Personally, I've not seen any problems with xmms (1.2.10) or xine that sound like this bug, even on my 6.1 systems. It is a glibc bug, not nvidia, xmms, xine, or OOo. Read the debian bug report mentioned elsewhere by DJ for the location of the test code to trigger it. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, 20 Nov 2005, Archaic wrote: On Sun, Nov 20, 2005 at 09:56:28PM +, Ken Moffat wrote: Personally, I've not seen any problems with xmms (1.2.10) or xine that sound like this bug, even on my 6.1 systems. It is a glibc bug, not nvidia, xmms, xine, or OOo. Read the debian bug report mentioned elsewhere by DJ for the location of the test code to trigger it. Ok, so the order in which libraries are loaded, together with a missing library, can trigger an assertion failure in glibc. Doctor, it hurts when I delete this library which has other libraries depending on it. -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, Nov 20, 2005 at 11:01:47PM +, Ken Moffat wrote: Ok, so the order in which libraries are loaded, together with a missing library, can trigger an assertion failure in glibc. Doctor, it hurts when I delete this library which has other libraries depending on it. In the test case the library was removed. In the live scenario there isn't a library deleted that I can see. A library that is needed claims to be dependant on another library which doesn't exist. However, it seems that the dependancy is dubious as the program runs fine without that library. This is also dependant on the environment the program sets up as noted by the fact the setting/unsetting the LD_LIBRARY_PATH affects whether the bug is triggered. Ultimately, it seems the bug is in allowing a library to depend on a non-existant library. If the library didn't exist at compile time, the compile should have failed. That's what I see from my cursory look. But the bottom line is that this is going to hit people building lfs-6.1.1. It's not very safe to assume these people will only use blfs-6.1.1 for their extra-lfs needs. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Matthew Burgess wrote: Note that BLFS-6.1 assumes LFS-6.1 as a base, therefore I'd think that BLFS-6.1.1 (if there is such a release) will assume LFS-6.1.1. As such, I don't consider OOo2 to be an issue as it's not in an existing release of BLFS. Xine may be a different issue, though as I said, we've still got time to fix this if someone can volunteer the necessary time to verify the bug and the effectiveness of the patch. I am undecided right now about a BLFS 6.1.1. One issue we had with 6.1 was openssh, but that was a glibc issue that I believe is fixed in LFS 6.1.1. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Ken Moffat wrote: Looking at the gentoo, debian, and blfs references, this seems to be triggered by (a) nvidia drivers, or (b) gnome (versions/items not specified), or (c) xmms (1.2.8? debian version) without libmikmod2, or (d) some OOo issue. From here, trying to trigger the bug looks like searching for a needle in a haystack. In the debian testsuite, there is a very easy testcase. http://bugs.debian.org/cgi-bin/bugreport.cgi/xbug.tar.gz?bug=219352;msg=209;att=1 (xbug.tar.gz) make clean make export LD_LIBRARY_PATH=.:/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib ./test_bug This should result in 'Success!' Then: rm lib3.so ./test_bug When working correctly, it should still show success. Unpatched glibc will trigger the 'Inconsistency' error. NVIDIA binary drivers are known to irritate this bug. At this point I don't know what else can initiate the error, but the error that is shown is bogus. The test case simulates the error by removing the lib so that they are effectively loaded in the incorrect order, but nothing in lib3.so is needed. I think that the deciding factor should be that this is acknowledged and fixed upstream. OTOH, it looks like BLFS can work arround it if needs be with an LD_PRELOAD line...It might be a pain to find them, but it can be done I suppose. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
Archaic wrote: On Sun, Nov 20, 2005 at 11:01:47PM +, Ken Moffat wrote: Ok, so the order in which libraries are loaded, together with a missing library, can trigger an assertion failure in glibc. Doctor, it hurts when I delete this library which has other libraries depending on it. In the test case the library was removed. In the live scenario there isn't a library deleted that I can see. No, there is nothing missing in the live scenario, as proven by using the LD_PRELOAD workaround. The lib is removed in the testcase only to trigger the message. Glibc simply should not be fussing about it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, Nov 20, 2005 at 08:58:03PM +, DJ Lucas wrote: I think that the deciding factor should be that this is acknowledged and fixed upstream. OTOH, it looks like BLFS can work arround it if needs be with an LD_PRELOAD line...It might be a pain to find them, but it can be done I suppose. It should be noted that LD_PRELOAD can be used to accomplish some nasty things and as such certain security enhanced patches will not allow the use of this variable at all. IOW, it's probably not best to use LD_PRELOAD as a workaround when the problem is known and fixed upstream. I will be running some tests. However, being Thanksgiving week, my schedule is rather stressed. I don't know if I will make the weekend deadline. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
