Bug 90337 - xastir program hangs on futex() system call
Summary: xastir program hangs on futex() system call
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-07 04:53 UTC by Paul Lutt
Modified: 2016-11-24 14:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-10-03 08:50:01 UTC
Embargoed:


Attachments (Terms of Use)

Description Paul Lutt 2003-05-07 04:53:42 UTC
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):
kernel-2.4.20-9

How reproducible:
Always

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 08:09:30 UTC
glibc issue or application bug

Comment 2 Ulrich Drepper 2003-05-09 03:20:50 UTC
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 20:19:47 UTC
Glibc version is 2.3.2-27.9:

glibc-common-2.3.2-27.9
glibc-2.3.2-27.9
glibc-devel-2.3.2-27.9


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

LD_ASSUME_KERNEL=2.4.1 export LD_ASSUME_KERNEL


Comment 5 Ulrich Drepper 2003-06-10 03:21:13 UTC
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 14:29:16 UTC
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 08:50:01 UTC
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.