Debian Bug report logs - #339827
linuxthreads crashes when using user stacks

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: David Given <dg@cowlark.com>

To: submit@bugs.debian.org

Subject: linuxthreads crashes when using user stacks

Date: Sat, 19 Nov 2005 01:59:22 +0000

[Message part 1 (text/plain, inline)]

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?

[Message part 2 (application/pgp-signature, inline)]

Message #10 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: David Given <dg@cowlark.com>, 339827@bugs.debian.org

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sat, 19 Nov 2005 00:10:20 -0500

On Sat, Nov 19, 2005 at 01:59:22AM +0000, 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

Message #15 received at 339827@bugs.debian.org (full text, mbox, reply):

From: David Given <dg@cowlark.com>

To: Daniel Jacobowitz <drow@false.org>

Cc: 339827@bugs.debian.org

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sun, 20 Nov 2005 01:03:34 +0000

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: David Given <dg@cowlark.com>

Cc: 339827@bugs.debian.org

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sun, 20 Nov 2005 12:17:26 -0500

On Sun, Nov 20, 2005 at 01:03:34AM +0000, 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

Message #25 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Christoph Hellwig <hch@lst.de>

To: Daniel Jacobowitz <drow@false.org>, 339827@bugs.debian.org

Cc: David Given <dg@cowlark.com>

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sun, 20 Nov 2005 20:08:17 +0100

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.

Message #30 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: Christoph Hellwig <hch@lst.de>

Cc: 339827@bugs.debian.org, David Given <dg@cowlark.com>

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sun, 20 Nov 2005 14:22:22 -0500

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

Message #35 received at 339827@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@sanori.org>

To: Daniel Jacobowitz <drow@false.org>, 339827@bugs.debian.org

Cc: Christoph Hellwig <hch@lst.de>, David Given <dg@cowlark.com>

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Tue, 20 Dec 2005 10:38:47 +0900

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
debian-devel@lists.  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
	sparcv9b	2.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

Message #40 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <drow@false.org>

To: GOTO Masanori <gotom@sanori.org>

Cc: 339827@bugs.debian.org, Christoph Hellwig <hch@lst.de>, David Given <dg@cowlark.com>

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Mon, 19 Dec 2005 21:29:43 -0500

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
> debian-devel@lists.  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
> 	sparcv9b	2.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

Message #45 received at 339827@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@sanori.org>

To: Daniel Jacobowitz <drow@false.org>

Cc: GOTO Masanori <gotom@sanori.org>, 339827@bugs.debian.org, Christoph Hellwig <hch@lst.de>, David Given <dg@cowlark.com>

Subject: Re: Bug#339827: linuxthreads crashes when using user stacks

Date: Sun, 01 Jan 2006 15:59:22 +0900

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
> > debian-devel@lists.  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
> > 	sparcv9b	2.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

Message #50 received at 339827@bugs.debian.org (full text, mbox, reply):

From: Petr Salinger <Petr.Salinger@t-systems.cz>

To: debian-gcc@lists.debian.org, <debian-glibc@lists.debian.org>, <debian-release@lists.debian.org>

Cc: 339827@bugs.debian.org, <226716@bugs.debian.org>

Subject: Re: TLS support (Re: linux-2.4 deprecated)

Date: Fri, 7 Apr 2006 20:06:10 +0200 (CEST)

> > > Current glibc does not support TLS under 2.4 kernels (see #226716), 
> > > so this is probalby glibc bug (some people call it feature).

> >  - provide TLS support for 2.4 kernels and an upgrade path? 

> 2.4 kernels does not have the necessary stuff to support TLS, 
> so that's not possible.

This feature is also arch and toolchain specific. 
Current glibc on alpha, powerpc, sparc, ia64, s390, amd64 
should work just now, someone (DD, of course) can verify it 
using test case from #226716 against sarge supported kernels.

Unofficial architectures kfreebsd-i386, kfreebsd-amd64, ppc64 
already support it.

i386 can be easily fixed when 
- support for real i386 hardware is dropped (already done)
- support for pre-2.4 kernels is dropped (seems planned, see #339827)

glibc fix contains two steps:
- add "libc_MIN_KERNEL_SUPPORTED=2.4.1" into debian/sysdeps/i386.mk
- copy linuxthreads/sysdeps/i386/i686/pt-machine.h into linuxthreads/sysdeps/i386/i486/pt-machine.h
  
Other architectures probably does not yet support __thread at all.

Petr

Message #55 received at 339827-done@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: 339827-done@bugs.debian.org

Subject: Bug#339827: linuxthreads crashes when using user stacks

Date: Tue, 11 Apr 2006 11:11:38 +0200

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

Send a report that this bug log contains spam.