Bug 90337 - xastir program hangs on futex() system call
xastir program hangs on futex() system call
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-05-07 00:53 EDT by Paul Lutt
Modified: 2016-11-24 09:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-03 04:50:01 EDT
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 Paul Lutt 2003-05-07 00:53:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Installed open source program xastir, which worked fine under RedHat 8.0.  When
I go to change maps in map chooser, program hangs.  Strace shows program waiting
on futex() system call.

Compiled and installed 2.4.20 generic kernel.  Only thing changed was booting
this kernel in place of 2.4.20-9 RH kernel.  Xastir runs fine with generic kernel.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install xastir, including geotiff map support.
2. Attempt to perform operation that scans geotiff maps.
3. Programs hangs in futex() call.

Additional info:
Comment 1 Arjan van de Ven 2003-05-07 04:09:30 EDT
glibc issue or application bug
Comment 2 Ulrich Drepper 2003-05-08 23:20:50 EDT
I never not even the slightest idea what xstir is.  You'll have to do some
debugging on your own.  Programs which use the runtime interfaces incorrectly
can show this kind of breakage.

Also, you have not specified what glibc version you are using.  Make sure you
have the latest which should be 2.3.2-27.9 in the moment.
Comment 3 Paul Lutt 2003-05-09 16:19:47 EDT
Glibc version is 2.3.2-27.9:

Comment 4 Paul Lutt 2003-06-04 16:28:38 EDT
I have been able to get around the futex() problem by setting the following
environment variable:

Comment 5 Ulrich Drepper 2003-06-09 23:21:13 EDT
Using LD_ASSUME_KERNEL makes the application use a different thread library.

If you cannot or don't want to investigate this further we can close the bug. 
Otherwise you need to do some investigation.
Comment 6 Paul Lutt 2003-06-10 10:29:16 EDT
Go ahead and close the bug.  I don't have enough knowledge about the system to
debug it any further without assistance.
Comment 7 Ulrich Drepper 2003-10-03 04:50:01 EDT
No way to reproduce and no way to debug it without users's help.  Closing.

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