Bug 105348 - Closing socket breaks the cancellation type of current thread
Summary: Closing socket breaks the cancellation type of current thread
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
Depends On:
Blocks: 98512 104701
TreeView+ depends on / blocked
Reported: 2003-09-25 09:32 UTC by Peter Stoldt
Modified: 2016-11-24 15:01 UTC (History)
2 users (show)

Fixed In Version: 2.3.2-4.80.8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-20 17:36:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Example program (1.62 KB, text/plain)
2003-09-25 09:34 UTC, Peter Stoldt
no flags Details
Makefile for the example (42 bytes, text/plain)
2003-09-25 09:35 UTC, Peter Stoldt
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:325 normal SHIPPED_LIVE : Updated glibc packages provide security and bug fixes 2003-11-12 05:00:00 UTC

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):

How reproducible:

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


Comment 7 Ulrich Drepper 2003-11-10 22:01:18 UTC
Should also be fixed in the test version of the RHL8 errata at


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.

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