Bug 150911

Summary:

exiting pthreads from an xterm process kills the xterm

Product:

[Fedora] Fedora

Reporter:

Adam Spanberger <aspanberger>

Component:

kernel

Assignee:

Dave Jones <davej>

Status:

CLOSED ERRATA

QA Contact:

Brian Brock <bbrock>

Severity:

high

Docs Contact:

Priority:

medium

Version:

CC:

pfrields, wtogami

Target Milestone:

---

Target Release:

---

Hardware:

i686

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2005-03-14 16:59:58 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Sample code to generate the problem	none

Description Adam Spanberger 2005-03-11 22:18:01 UTC

Description of problem:
I have a simple application that creates pthreads.  The behavior is the same 
whether the thread is detached or whether I try to join to it.  When I run the 
application from a normal terminal, it works as expected.  If I try to run it 
in its own xterm (ie. xterm -e appName), the xterm dies as soon as the first 
thread exits.

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

How reproducible:
Very.  I was also able to reproduce it by running the application using a 
dejagnu script.

Steps to Reproduce:
1.gcc threadTest.c -lpthread 
2.xterm -e ./a.out
3.
  
Actual results:
xterm exits after first thread exits.

Expected results:
xterm exits when all five threads of the parent process exit

Additional info:
LD_ASSUME_KERNEL <= 2.4.19 works
LD_ASSUME_KERNEL >= 2.4.20 does not work

I'm providing a very simple test case that demonstrates the problem.

Comment 1 Adam Spanberger 2005-03-11 22:18:02 UTC

Created attachment 111904 [details]
Sample code to generate the problem

Comment 2 Dave Jones 2005-03-11 22:19:51 UTC

is this repeatable with the errata kernel ?
2.6.9-1.667 is ancient now.

Comment 3 Adam Spanberger 2005-03-14 14:44:55 UTC

Updating to 2.6.10-1.770 fixed the problem.  Thanks for your help.