[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#339827: marked as done (linuxthreads crashes when using user stacks)

Your message dated Tue, 11 Apr 2006 11:11:38 +0200
with message-id <20060411091138.GA30215@bode.aurel32.net>
and subject line Bug#339827: linuxthreads crashes when using user stacks
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
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?

Attachment: pgp3Otk0xPVQU.pgp
Description: PGP signature


--- End Message ---
--- Begin Message --- 
The new glibc (2.3.6-6) is now built with TLS support for 2.4 kernels.
This bug is therefore fixed. Closing it.


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: