Bug 97636 - LTC3150-RedHat EL3 Alpha 3: pthread_mutex_destroy() can destroy a locked mutex
LTC3150-RedHat EL3 Alpha 3: pthread_mutex_destroy() can destroy a locked mutex
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc3 (Show other bugs)
3.0
powerpc Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-18 12:47 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-18 14:14:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2003-06-18 12:47:11 EDT
The following has be reported by IBM LTC:  
RedHat EL3 Alpha 3: pthread_mutex_destroy() can destroy a locked mutex
Please fill in each of the sections below.

Hardware Environment:
2-way POWER3
Software Environment:
RedHat EL3 Alpha 3

Steps to Reproduce:
On Redhat EL3 Alpha 3, pthread_mutex_destroy() can successfully destroy a
mutex while it is locked.

The Linux man page of pthread_mutex_destroy() says:
   The pthread_mutex_destroy function returns the following error code  on
   error:
     EBUSY  the mutex is currently locked.

The IEEE Std 1003.1, 2003 (POSIX) standard specifies:
   The pthread_mutex_destroy() function may fail if:
   [EBUSY] 
   The implementation has detected an attempt to destroy the object
   referenced by mutex while it is locked or ....

Test case and execution:
/home/xxue/work> cat destroymutex.c
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
pthread_mutex_t mymutex=PTHREAD_MUTEX_INITIALIZER;
int
main()
{
  int              rc;

  pthread_mutex_lock(&mymutex);
  rc = pthread_mutex_destroy(&mymutex);
  if (rc != 0)
  {
      printf("Error from pthread_mutex_destroy() <%s>.\n", strerror(rc));
  }
  else {
      printf("pthread_mutex_destroy() returns <%d>.\n", rc);
  }
}
/home/xxue/work> gcc destroymutex.c -lpthread
/home/xxue/work> a.out
pthread_mutex_destroy() returns <0>.

The same test case works as expected on other platforms, including SLES8:
/home/xxue/work> gcc destroymutex.c -lpthread
/home/xxue/work> a.out
Error from pthread_mutex_destroy() <Device or resource busy>.

1.
2.
3.

Actual Results:

Expected Results:

Additional Information:Mike - I know this is an alpha bug (against RHEL 3.0
Alpha), but I'd like to
ask if you can check the relevant POSIX standard for this issue before
we send it off to Red Hat.  Thanks.I found a thread of discussion about this on
a Red Hat-oriented message board, 
though none of the people in the thread are from Red Hat. Apparently this 
behaviour is undefined in POSIX and therefore optional. Error-checking of this 
nature is left otional to allow better performance in environments where the 
application can be trusted to be well-written.

Here is the link to the discussion:

http://sources.redhat.com/ml/pthreads-win32/2001/msg00065.html

Here is a link to a detailed discussion of pthread_mutex_destroy() on the Open 
Group site:

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_destroy.ht
ml

It confirms this error-checking *may* be implemented, but it is optional (note 
the word *may* in Xing Xue's quote of the standard in the bug description 
above). *Shall* would be the word used for required implementation. This 
document references IEEE Std 1003.1, 2003 Edition, so we know this is current 
information.

I tried the test on RHAS 2.1 and it failed, so apparently this behaviour 
changed going from Linuxthreads in RHAS 2.1 to NPTL in RHEL Alpha 3. 

I verified the man page under RHAS 2.1 does indicate that this should return an 
error. If RHEL Alpha 3 is showing the same man page, perhaps the bug is that 
they have not updated the thread library man pages for NPTL.

But as far as this being a POSIX incompatibility, I recommend rejecting this 
bug as NOTABUG.
Given the POSIX standard says it "may" fail, I don't think we should rush
into the conclusion 'NOTABUG'.  I'd suggest to verify with Redhat
to see if this is the designed behavior of NPTL.Either NPTL is exibiting the
wrong behavior or Red Hat has not updated the man 
pages for RHEL Alpha 3 (more likely). In any case, a bug exists, so we will 
assign this bug to Red Hat.
Comment 1 Ulrich Drepper 2003-06-18 14:14:02 EDT
This is indeed no bug and your test program will continue to not work.

I added a test to detect *some* cases in which a mutex is still in use for erorr
checking mutexes.  But not for any other.  But even that test won't catch all
cases (neither did the one in LinuxThreads).  The remaining cases can be handled
only with major performance impacts which is why it won't be done.

As for the man pages: they are written as part of LinuxThreads and document that
implementation.  Feel free to contribute edits.
Comment 2 IBM Bug Proxy 2003-06-20 10:51:22 EDT
------ Additional Comments From khoa@us.ibm.com  2003-19-06 18:59 -------
Glen - please specify in the RH bug report that the purpose of the bug
report is to fix the man page.  I think we already accepted that this
is not a real functional bug.  Thanks.

 
Comment 3 IBM Bug Proxy 2003-06-23 16:25:59 EDT
------ Additional Comments From sjmunroe@us.ibm.com  2003-23-06 14:00 -------
This is fixed in nptl-0.48. 

Still need to find out if this will be in RHEL 3 (RHEL 3 Alpha 3 was at nptl-
0.38).

 
Comment 4 IBM Bug Proxy 2003-06-23 18:02:19 EDT
------ Additional Comments From xingxue@ca.ibm.com  2003-23-06 14:18 -------
Looks like the NPTL was fixed.  Just to make sure, is it the man page or the
NPTL got fixed?  Since Ulrich said it was not a bug....

 

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