Bug 81212 - glibc-2.3.1 threads support does not work if machine's kernel lacks support for kernel-side futexes.
glibc-2.3.1 threads support does not work if machine's kernel lacks support f...
Product: Red Hat Public Beta
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: 79578
  Show dependency treegraph
Reported: 2003-01-06 15:12 EST by Oleg Drokin
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-08 20:18:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Oleg Drokin 2003-01-06 15:12:17 EST
Description of problem:
If I run thread-enabled applications (mozilla, identd for example), they clone
several threads that are then busylooping doing ioctls (parameters say something
about futexes) and contstantly getting errors in return (sure, vanilla 2.4
kernels do not have this support) (observed with strace).
This is both with glibc-3.2.1 from Phoebe beta and with current rawhide release

How reproducible:

Steps to Reproduce:
Just boot into vanilla 2.4 kernel and try to start identd

Actual results:
several threads are started and start to eat all the CPU  they can get.
These threads are only observable using m switch to "ps" command.

Expected results:
identd is supposed to sit idle waiting for requests.
Comment 2 Nathan G. Grennan 2003-01-07 09:01:47 EST
I have glibc-2.3.1-30 installed and I don't see this with Mozilla or identd. I
don't remember seeing it after installing Phoebe either. I would think people
would have noticed very quickly if processes started eatting the cpu.
Comment 3 Oleg Drokin 2003-01-07 13:35:54 EST
As I already have said, this CPU-eating can only be observed if one uses vanilla
2.4 kernel with glibc-2.3.1. Here is example from my box:
[root@car root]# uname -a
Linux car.linuxhacker.ru 2.4.20 #2 SMP Sun Dec 1 20:13:04 MSK 2002 i686 i686
i386 GNU/Linux
[root@car root]# /etc/rc.d/init.d/identd start
[root@car root]# ps axm | grep ident
 1523 ?        S      0:00 identd
 1526 ?        R      1:24 identd
 1528 ?        R      1:24 identd
 1525 ?        R      1:22 identd
[root@car root]# strace -p 1526
futex(0x8052b20, FUTEX_WAKE, 1, NULL)   = -1 ENOSYS (Function not implemented)
futex(0x8052b2c, FUTEX_WAIT, 0, NULL)   = -1 ENOSYS (Function not implemented)
futex(0x8052b2c, FUTEX_WAIT, 0, NULL)   = -1 ENOSYS (Function not implemented)
futex(0x8052b2c, FUTEX_WAIT, 0, NULL)   = -1 ENOSYS (Function not implemented)
futex(0x8052b20, FUTEX_WAIT, 2, NULL)   = -1 ENOSYS (Function not implemented)
Comment 4 Nathan G. Grennan 2003-01-08 01:20:54 EST
I just read the comment, and not the full summary. Bugzilla cuts off the summary
when listing bug reports in a search. You might want to be more clear in the
comment next time, though I should have read the summary in full.
Comment 5 Nathan G. Grennan 2003-01-08 01:23:09 EST
I could see this being a major problem for people that load vanilla kernels
without knowing better. It would seem if RedHat plans to include the new glibc
in 8.1 they better convince Marco to include the futex patch in the vanilla
kernel, and be sure to make a big comment in the release notes.
Comment 6 Warren Togami 2003-01-08 16:04:28 EST
Or can glibc have a fall-back mechanism to use the old threads model?  Many
people will have problems because they *must* use vanilla kernels with some
proprietary or non-standard OSS kernel patch.  While they aren't supported, they
were able to use their own kernels in all previous Red Hat versions but they
suddenly wont be able to do so in RH8.1+.

Phoebe rpm initially had a similar problem to this but a fallback mechanism was
added later in Rawhide, if I understand correctly.
Comment 7 Jakub Jelinek 2003-01-08 20:18:25 EST
glibc-2.3.1-32 and later conditionalize use of NPTL and TLS on AT_SYSINFO tag.

Note You need to log in before you can comment on or make changes to this bug.