Bug 112602 - Strange pthread_testcancel exception behavior
Summary: Strange pthread_testcancel exception behavior
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: 1
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-24 09:05 UTC by Scott Lamb
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-06 20:54:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
demonstration program (4.50 KB, text/plain)
2003-12-24 09:06 UTC, Scott Lamb
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:143 normal SHIPPED_LIVE GNU C Library bugfix update 2004-05-11 04:00:00 UTC
Red Hat Product Errata RHBA-2004:212 normal SHIPPED_LIVE Updated shadow-utils package available 2004-05-11 04:00:00 UTC
Red Hat Product Errata RHBA-2004:213 normal SHIPPED_LIVE Updated ypserv package available 2004-05-11 04:00:00 UTC

Description Scott Lamb 2003-12-24 09:05:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
I'm getting weird exception behavior from pthread_testcancel(). Based
on exactly where I place it, it seems to either throw a C++ exception
or not. If it does throw an exception, it calls std::unexpected().

The std::unexpected() part I can begin to explain. My
/usr/include/pthread.h is identical to
linuxthreads/sysdeps/pthread/pthread.h in current glibc CVS, not
nptl/sysdeps/pthread/pthread.h. It has __THROW clauses in a lot of
places that are cancelable: pthread_testcancel(),
pthread_setcancelstate(), pthread_setcanceltype(),
pthread_cleanup_pop_restore_np() jump out at me. Is this just a case
of the wrong header getting installed in the glibc-devel package?

In addition to glibc-2.3.3-1, I have glibc-devel-2.3.3-1, gcc-3.3.2-1,
kernel-2.4.22-1.2115.nptl.

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

How reproducible:
Always

Steps to Reproduce:
Compile test_cancellation_exception.cc with and without
-DSEE_WEIRD_FEDORA_BEHAVIOR and run it.

Actual Results:  Without -DSEE_WEIRD_FEDORA_BEHAVIOR,
Testing nanosleep:
Cancellation exception type: generic
Cancellation invokes destructors.

Testing pthread_testcancel inside else:
terminate called without an active exception
Aborted


With -DSEE_WEIRD_FEDORA_BEHAVIOR:
Testing pthread_testcancel directly:
Cancellation exception type: none
Cancellation does not invoke destructors.

Expected Results:  Without -DSEE_WEIRD_FEDORA_BEHAVIOR:

Testing nanosleep:
Cancellation exception type: generic
Cancellation invokes destructors.

Testing pthread_testcancel inside else:
Cancellation exception type: generic
Cancellation invokes destructors.


With -DSEE_WEIRD_FEDORA_BEHAVIOR:
Testing pthread_testcancel directly:
Cancellation exception type: generic
Cancellation invokes destructors.

Comment 1 Scott Lamb 2003-12-24 09:06:24 UTC
Created attachment 96691 [details]
demonstration program

Comment 3 Scott Lamb 2004-01-06 20:54:30 UTC
Works now with glibc-2.3.3-3. Thanks.

(Out of curiosity, why was my -DSEE_WEIRD_FEDORA_BEHAVIOR causing it
to do the old-style cancellation without a C++ exception? I don't see
that mentioned in your mailing list post.)

Comment 4 John Flanagan 2004-05-12 01:28:23 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-212.html



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