Bug 81212 - glibc-2.3.1 threads support does not work if machine's kernel lacks support for kernel-side futexes.
Summary: glibc-2.3.1 threads support does not work if machine's kernel lacks support f...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: glibc
Version: phoebe
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
 
Reported: 2003-01-06 20:12 UTC by Oleg Drokin
Modified: 2016-11-24 14:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-09 01:18:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Oleg Drokin 2003-01-06 20:12:17 UTC
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
2.3.1-30

How reproducible:
Easily

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 14:01:47 UTC
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 18:35:54 UTC
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 06:20:54 UTC
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 06:23:09 UTC
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 21:04:28 UTC
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-09 01:18:25 UTC
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.