Bug 105348 - Closing socket breaks the cancellation type of current thread
Closing socket breaks the cancellation type of current thread
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks: 98512 104701
  Show dependency treegraph
 
Reported: 2003-09-25 05:32 EDT by Peter Stoldt
Modified: 2016-11-24 10:01 EST (History)
2 users (show)

See Also:
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 12:36:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 05:34 EDT, Peter Stoldt
no flags Details
Makefile for the example (42 bytes, text/plain)
2003-09-25 05:35 EDT, Peter Stoldt
no flags Details

  None (edit)
Description Peter Stoldt 2003-09-25 05:32:39 EDT
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 05:34:45 EDT
Created attachment 94708 [details]
Example program

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

Makefile to create the example program
Comment 5 Jakub Jelinek 2003-10-03 05:38:30 EDT
ATM this is fixed in glibc-2.3.2-95.3 (RHEL3).
Comment 6 Ulrich Drepper 2003-11-04 16:48:24 EST
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 17:01:18 EST
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 12:36:38 EST
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.