Bug#339827: linuxthreads crashes when using user stacks
At Mon, 19 Dec 2005 21:29:43 -0500, Daniel Jacobowitz wrote: On Tue, Dec 20, 2005 at 10:38:47AM +0900, GOTO Masanori wrote: At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. No, it isn't :-( I didn't get around to it; if you could, that would be great. Okay, I see. It's time to transit. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. Might want to check with the s390x and sparc porters, too. If 2.4 is dead for those architectures, we don't need to carry it around. ARM could probably use a bump, but I'm not sure to what. Thanks for your comments. I'll consider about such architectures. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Tue, Dec 20, 2005 at 10:38:47AM +0900, GOTO Masanori wrote: At Sun, 20 Nov 2005 14:22:22 -0500, Daniel Jacobowitz wrote: Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? Is it already done? If it's pended, I'll ask it to [EMAIL PROTECTED] The security support for 2.2 series was finished, we have no reason to support 2.2 kernel. No, it isn't :-( I didn't get around to it; if you could, that would be great. Note that the current status of the support kernel versions are: amd64 2.6.0 i386(i686) 2.6.0 i386(amd64) 2.6.0 *(nptl) 2.6.0 ppc64 2.6.0 s390x 2.4.1 sparc64 2.4.18 sparcv9 2.4.18 sparcv9b2.4.18 others 2.2.0 They'll be changed to: i386(i486) 2.4.1 powerpc 2.4.1 (?) BTW, note that some architectures like m68k could not compile the recent glibc with kernel 2.4.x or 2.6.x. Might want to check with the s390x and sparc porters, too. If 2.4 is dead for those architectures, we don't need to carry it around. ARM could probably use a bump, but I'm not sure to what. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Sun, Nov 20, 2005 at 01:03:34AM +, David Given wrote: On Saturday 19 November 2005 05:10, Daniel Jacobowitz wrote: [...] We could ship a fourth variant of fifth variant of glibc for i686 using LinuxThreads. I am not particularly motivated to do this considering how rarely anyone encounters this problem, and the corresponding cost in archive space, build time, and maintenance. (There are lots of references to TLS in the linuxthreads code, all in files in the sysdeps/i386 directory. I assume that this is only used on i686 and above, and that i386 systems genuinely *don't* support TLS, and this isn't just an oversight?) It's support code for the i686 case - mostly. See below. Since this *is* a bug in linuxthreads, no matter how obscure, I'm hoping that it's less effort all around to simply fix it... but the alternatives all seem to involve keeping a shared data structure between threads containing all the necessary information. I suspect that maintaining this structure is going to be considerably more work than it first appears. It's only less effort all around because you wouldn't have to do any of it. Don't you think that someone would have fixed this well-documented limitation in the last eight or so years if there was a practical fix? There isn't. These options work: - Drop kernel 2.2 support. I wouldn't mind doing this, but there may be some opposition; we still get 2.2.x kernel users periodically. When glibc is built to assume 2.4 kernels it can handle alternate stacks. - Built Yet Another variant of glibc, requiring either 2.4 or i686. This is a maintenance burden for us. I'll ask around about 2.2 kernels. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Sun, Nov 20, 2005 at 12:17:26PM -0500, Daniel Jacobowitz wrote: It's only less effort all around because you wouldn't have to do any of it. Don't you think that someone would have fixed this well-documented limitation in the last eight or so years if there was a practical fix? There isn't. These options work: - Drop kernel 2.2 support. I wouldn't mind doing this, but there may be some opposition; we still get 2.2.x kernel users periodically. When glibc is built to assume 2.4 kernels it can handle alternate stacks. I think dropping support for 2.2 kernel on x86 is fine. The only 2.2 kernel-images still in unstable are for m68k. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Sun, Nov 20, 2005 at 08:08:17PM +0100, Christoph Hellwig wrote: On Sun, Nov 20, 2005 at 12:17:26PM -0500, Daniel Jacobowitz wrote: It's only less effort all around because you wouldn't have to do any of it. Don't you think that someone would have fixed this well-documented limitation in the last eight or so years if there was a practical fix? There isn't. These options work: - Drop kernel 2.2 support. I wouldn't mind doing this, but there may be some opposition; we still get 2.2.x kernel users periodically. When glibc is built to assume 2.4 kernels it can handle alternate stacks. I think dropping support for 2.2 kernel on x86 is fine. The only 2.2 kernel-images still in unstable are for m68k. Steve Langasek agreed. I am planning to bump the requirement up from 2.2.whatever to 2.4.0 for i486 and powerpc; i486 in order to enable floating stacks, and powerpc because we've been getting bug reports that indicate that static binaries are already broken there under 2.2, and no one wants to debug it. Any objections before I do this? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339827: linuxthreads crashes when using user stacks
On Saturday 19 November 2005 05:10, Daniel Jacobowitz wrote: [...] We could ship a fourth variant of fifth variant of glibc for i686 using LinuxThreads. I am not particularly motivated to do this considering how rarely anyone encounters this problem, and the corresponding cost in archive space, build time, and maintenance. I understand your reasoning, but unfortunately it still leaves me in the lurch. I'm the author of the application in question, and I was hoping to do a Debian package for it. The current situation is that it simply won't work on Debian systems with a 2.4 kernel. The only possible workaround is to have the package compile its own version of the library, without pthreads support, which is a maintenance nightmare. (There are lots of references to TLS in the linuxthreads code, all in files in the sysdeps/i386 directory. I assume that this is only used on i686 and above, and that i386 systems genuinely *don't* support TLS, and this isn't just an oversight?) Since this *is* a bug in linuxthreads, no matter how obscure, I'm hoping that it's less effort all around to simply fix it... but the alternatives all seem to involve keeping a shared data structure between threads containing all the necessary information. I suspect that maintaining this structure is going to be considerably more work than it first appears. pgpvBQJ5OPMoY.pgp Description: PGP signature
Bug#339827: linuxthreads crashes when using user stacks
Package: glibc Version: 2.3.5-8 Severity: important When using 2.4 kernels, the linuxthreads library makes an incorrect assumption about stack usage that causes applications to crash if they use user stacks. This does not occur on 2.6 kernels (because they use a different threading library). I haven't tested this on 2.2 or below. The reason: because 2.4 kernels don't support thread local storage, linuxthreads puts a pointer to its current thread state just beyond the end of the stack block. By looking at the stack pointer, it can work out whether it's in the initial thread, the manager thread, or one of its slave threads. Unfortunately, using a user stack causes the logic to go wrong, resulting in it following a bogus pointer and dying. (See linuxthreads/descr.h, about line 250.) The case where I am running across this bug is as follows: I have an application that uses coroutines, implemented with setcontext/getcontext. Each coroutine gets its on stack. The application itself does not use pthreads. However, the application is linked with libsqlite3, which on Debian has been compiled with pthread support; this causes the linker to use the thread-aware version of malloc(), which on 2.4 kernels causes the application to die the first time it does a memory allocation from a coroutine. It works fine on 2.6 kernels and on non-Linux pthread implementations. (I suspect this would fail if a pthread-aware function was called from a signal handler set up to use an alternate stack with sigaltstack() as well; but this is less important as the available functionality in signal handlers is so limited.) linuxthreads *does* have a workaround that appears to solve a related problem, but it is enabled by setting an internal switch (the __pthread_nonstandard_stacks variable), which is not publicly accessible, and it still relies on letting pthreads initialise the stack frame. (This is used when a thread is created with an explicit stack specified.) This would not help in this situation. This bug is causing the application to be unusable on Debian systems with a 2.4 kernel. The current workaround I'm suggesting is to compile a private copy of the Sqlite library without pthreads enabled, and statically linking against that; this is not really satisfactory. Unfortunately, I can't suggest a fix --- this appears to be a fundamental design problem with linuxthreads. This appears on current Debian unstable systems. The application in question is Spey, available from http://spey.sf.net; this can be reliably reproduced on 2.4 kernel systems. Is there any more information that would be useful? pgpaG2tdBCjPj.pgp Description: PGP signature
Bug#339827: linuxthreads crashes when using user stacks
On Sat, Nov 19, 2005 at 01:59:22AM +, David Given wrote: The reason: because 2.4 kernels don't support thread local storage, That's not, in fact, true. LinuxThreads uses thread local storage when configured for i686. The only i686-configured C libraries we ship for x86 at this point in time use NPTL and require a 2.6 kernel. This bug is causing the application to be unusable on Debian systems with a 2.4 kernel. The current workaround I'm suggesting is to compile a private copy of the Sqlite library without pthreads enabled, and statically linking against that; this is not really satisfactory. Unfortunately, I can't suggest a fix --- this appears to be a fundamental design problem with linuxthreads. This appears on current Debian unstable systems. The application in question is Spey, available from http://spey.sf.net; this can be reliably reproduced on 2.4 kernel systems. Is there any more information that would be useful? We could ship a fourth variant of fifth variant of glibc for i686 using LinuxThreads. I am not particularly motivated to do this considering how rarely anyone encounters this problem, and the corresponding cost in archive space, build time, and maintenance. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
