Bug 167162 - tog-pegasus is not compatible with NPTL
tog-pegasus is not compatible with NPTL
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: tog-pegasus (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Stein
Depends On:
Blocks: 156322
  Show dependency treegraph
Reported: 2005-08-31 04:05 EDT by Brian Stein
Modified: 2013-03-01 00:14 EST (History)
3 users (show)

See Also:
Fixed In Version: RHEA-2005-494
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 09:43:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Arjan van de Ven 2005-08-31 04:05:53 EDT
Description of problem:

In member function 'void Pegasus::Thread::cleanup_push(void (*)(void*), void*)':
error: '_pthread_cleanup_push' was not declared in this scope
In member function 'void Pegasus::Thread::cleanup_pop(Pegasus::Boolean)':
error: '_pthread_cleanup_pop' was not declared in this scope

these are linuxthread internals that cannot work according to jakub
Comment 1 Jason Vas Dias 2005-08-31 11:18:26 EDT
This issue is fixed with the "tog-pegasus-2.4.1-Beta3-gcc4.patch" submitted
for the Fedora Rawhide version, where NPTL threads are now the default.

As of the current glibc-2.3.4-2.12 / gcc-3.4.4-2 in RHEL-4-U2, tog-pegasus 
compiles with no errors. 

Are we now, at this late stage, planning to change basic glibc behaviour for
RHEL-4-U2 ? If so, I think this is a very bad idea - tog-pegasus is not the
only package that this will break.

I see there is a new glibc-2.3.4-2.13 in the /mnt/redhat/nightly/RHEL4-U2-re0831
but this has not been incorporated into the released U2 in 
/mnt/redhat/released/RHEL-4/U2-Beta, which still has the glibc-2.3.4-2.12 

I'm now testing the tog-pegasus build with libc-2.3.4-2.13, but can anyone
tell me which glibc version is going into the final U2 ? 
Comment 2 Arjan van de Ven 2005-08-31 11:19:53 EDT
NTPL has been the default threading library *at runtime* always for RHEL4.
Nothing is changing in this regard....
Comment 3 Jason Vas Dias 2005-08-31 11:37:44 EDT
Well, what glibc version were you trying to build with ? 
This problem does not happen when compiling with the glibc-2.3.4-2.12 version.
The problem only occurs in Rawhide because the NPTL headers no longer declare
these prototypes in pthread.h:
 extern void _pthread_cleanup_push (struct _pthread_cleanup_buffer * buffer,
                                    void (*routine)(void *), void * arg);

 extern void _pthread_cleanup_pop  (struct _pthread_cleanup_buffer * buffer,
                                    int execute);
But the headers from glibc-2.3.4-2.12 DO declare them, so the build succeeds.

The patch for rawhide reinstates these missing declarations in tog-pegasus'
threads header .

I did investigate trying the recommended approach of using the 
pthread_cleanup_{pop,push} macros, which MUST be used within the
same scope ({ } block) , but this would entail a radical redesign
of the whole tog-pegasus Thread class which would be a major deviation
from the upstream version and which could be incompatible with existing
third-party client code.
Also the test RPM has an extensive test-suite for the threads functionality
which passes with both RHEL-4's glibc-2.3.4-2.12 and Rawhide's glibc-2.3.90-10 .

Which glibc are you using ?
Comment 4 Jason Vas Dias 2005-08-31 11:56:26 EDT
Moreover, the dist-4E-build buildroot used by the build servers still has 
glibc-2.3.4-2.9 , so this issue really seems not to be a problem with the
current glibc versions being used in RHEL-4 .
Comment 5 Arjan van de Ven 2005-08-31 11:58:57 EDT
the problem isn't that this junk doesn't build
the problem is that it won't function correctly because NPTL does not emulate
this level of internals of linuxthreads correctly.
Comment 6 Jakub Jelinek 2005-08-31 12:01:53 EDT
_pthread_cleanup_{push,pop} is a LinuxThreads compatibility interface only.
No new program should ever use it, especially from C++ code where it can't do
the expected job when intermixed with normal C++ destructors (which are
called during thread cancellation by NPTL as well).
Comment 7 Ulrich Drepper 2005-08-31 12:15:26 EDT
The _pthread_cleanup_{push,pop} really don't do much.  They add/remove the
provided record from/to an internal list and eventually call the handler in the
_pop function.  This is nothing which this code couldn't do on its own.

Using the _pthread_cleanup_{push,pop} functions is bad and dangerous since the
use of the internal list of cleanup handlers can be screwed up.  The handlers
might not be looked at in the correct order and all is lost.

Work around this by simply changing the class of _cleanup to contain a
single-linked list of cleanup_handler objects and do all the push/pop explicitly
yourself.  The code won't be any longer but much more robust.
Comment 8 Jason Vas Dias 2005-08-31 12:29:01 EDT
OK, I will try to use the method described in the last comment for the 
next release, if it does not require the Thread class to change, is
accepted upstream, and the thread test suite still passes.

The threads portion of the test suite does pass all tests with the current
glibc-2.3.4-2.12 version in RHEL-4.

If this bug report is about tog-pegasus threads not functioning correctly, then
the problem description should have mentioned this with a reproducible example
of the failure - instead, it mentions only the failure to build, which I cannot
reproduce with current RHEL-4 glibc versions.
Comment 9 Jason Vas Dias 2005-08-31 21:06:12 EDT
This is now fixed in tog-pegasus-2.4.1-3.rhel4+ , as for upstream bug 4025:

Comment 10 Jason Vas Dias 2005-09-01 07:08:53 EDT
This is now fixed in tog-pegasus-2.4.1-4.rhel4 .
The package uses its own internal implementation of 
pthread_cleanup_{push,pop} on other OS's; this is now
used also for Linux in the upstream code.
Comment 11 Jason Vas Dias 2005-09-01 07:10:04 EDT
Upstream bug: http://cvs.rdg.opengroup.org/bugzilla/show_bug.cgi?id=4025
Comment 12 Red Hat Bugzilla 2005-10-05 09:43:55 EDT
An advisory 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.


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