Bug 144247 - sem_wait fails with EINTR when running in gdb
Summary: sem_wait fails with EINTR when running in gdb
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Alexandre Oliva
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-05 11:16 UTC by Rian Wouters
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-28 19:03:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rian Wouters 2005-01-05 11:16:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET 
CLR 1.1.4322)

Description of problem:
This problem is looks similar to problem 5329, 
but has apparently never been filed for fc1.

When running outside gdb my program runs fine.
However when running in gdb, sem_wait fails with return value !=0
and errno=EINTR

I tried to replace 
if (sem_wait(...) != 0)
  "error handling"


while (sem_wait(...) != 0) { }

however, now some thread receives I get SIGTRAP signal first,
and immediately after the process gets a SIGSEGM signal.

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

How reproducible:

Steps to Reproduce:
will be added later, still busy to isolate the problem

Actual Results:   gdb stops

Expected Results:   gdb should be operational

Additional info:


Comment 1 Rian Wouters 2005-01-10 12:04:25 UTC
Some logging related to this:

inside the sig_handler 5
Signal 5, exiting...
Process #2998 received signal 11
Process #2998 being suspended
Process #2998 received signal 11
Process #2998 being suspended
Program received signal SIGSTOP, Stopped (signal).
[Switching to Thread -1085205856 (LWP 2998)]
0x00232c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

Comment 2 Matthew Miller 2006-07-11 17:23:47 UTC
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.


NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.

Comment 3 John Thacker 2006-10-28 19:03:12 UTC
Note that FC1 and FC2 are no longer supported even by Fedora Legacy.  Please
install a still supported version and retest.  If this still occurs on FC3 or
FC4 and is a security issue, please reopen and assign to that version and Fedora
Legacy.  If it still occurs on FC5 or FC6, please reopen and assign to the
correct version.

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