Bug 105348

Summary: Closing socket breaks the cancellation type of current thread
Product: [Retired] Red Hat Linux Reporter: Peter Stoldt <peter_stoldt>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: drepper, fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 2.3.2-4.80.8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-11-20 17:36:38 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:
Bug Depends On:    
Bug Blocks: 98512, 104701    
Attachments:
Description Flags
Example program
none
Makefile for the example none

Description Peter Stoldt 2003-09-25 09:32:39 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20030906

Description of problem:
A call to close() sets a wrong value of the pthread cancellation type while a
call to pthread_setcanceltype() fixes this value.

We have two systems, one machine is running on a i586 CPU and the other machine
is running on a i686 dual CPU configuration. The installation is a Red Hat Linux
8.0 with the updated glibc 2.3.2.

 * The Kernel on the i586 system is the default kernel from the CD 
 * The kernel on the i686 system is the latest available kernel
   found on Red Hat's FTP site.
 * The glibc on the i686 system is for the i686 architecture
 * The the glibc on the i586 system is for the i386 architecture

The behaviour of the sample program is differently on both systems. On the i586
system it is incorrect, and on the i686 system it is correct as long as the
environment variable LD_ASSUME_KERNEL is not set to 2.2.5 or tho 2.4.0. When it
is set, it behaves the same as on the i586 system (ie it demonstrates the bug).
However we were able to reproduce the problem on another i686 machine as well,
without setting the environment variable LD_ASSUME_KERNEL, but the application
we were running there is not quite as simple as the attached sample program.

Note that the sample program works fine on a default glibc which
ships with Red Hat Linux 8.0 (glibc 2.2.93) on both machines.


Version-Release number of selected component (if applicable):
glibc-common-2.3.2-4.80.6

How reproducible:
Always

Steps to Reproduce:
1. Compile the appended example program using the Makefile

2. Execute the binary on an unpatched RH 8.0 system with glibc 2.2.9x

3. Execute the binary on a patched RH 8.0 system with glibc 2.3.2

Actual Results:  Incorrect output (glibc 2.3.2):

creating new thread thread_id = 0
B0 rc=0 new=0  old=0
B1 rc=0 new=0  old=40
error: 0 Success
B2 rc=22 new=40  old=40
B3 rc=0 new=0  old=0
thr func end


Expected Results:  Correct output (glibc 2.2.9x):

creating new thread thread_id = 0
B0 rc=0 new=0  old=0
B1 rc=0 new=0  old=0
B2 rc=0 new=0  old=0
B3 rc=0 new=0  old=0
thr func
thr func end


Additional info:
Comment 1 Peter Stoldt 2003-09-25 09:34:45 UTC 
Created attachment 94708 [details]
Example program

Example program to reproduce the problem
Comment 2 Peter Stoldt 2003-09-25 09:35:27 UTC 
Created attachment 94709 [details]
Makefile for the example

Makefile to create the example program
Comment 5 Jakub Jelinek 2003-10-03 09:38:30 UTC 
ATM this is fixed in glibc-2.3.2-95.3 (RHEL3).
Comment 6 Ulrich Drepper 2003-11-04 21:48:24 UTC 
Fixed in the RHL9 errata.  Test version at

  ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.4/
Comment 7 Ulrich Drepper 2003-11-10 22:01:18 UTC 
Should also be fixed in the test version of the RHL8 errata at

  ftp://people.redhat.com/drepper/glibc-errata/rhl8/


Please test and let us know whether it works or not.
Comment 8 Ulrich Drepper 2003-11-20 17:36:38 UTC 
No response received.  I assume the bug is fixed.  Reopen in case you
still see problems.