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?
pgpRxiyMZvH30.pgp
Description: PGP signature