From owner-freebsd-doc@FreeBSD.ORG Tue Mar 3 10:40:14 2015 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D441763 for ; Tue, 3 Mar 2015 10:40:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62B27619 for ; Tue, 3 Mar 2015 10:40:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t23AeEnU058448 for ; Tue, 3 Mar 2015 10:40:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-doc@FreeBSD.org Subject: [Bug 198216] According to man page for pthread_cond_destroy it returns EBUSY error code, but it never does Date: Tue, 03 Mar 2015 10:40:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Documentation X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: msiodelski@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-doc@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform bug_file_loc op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 10:40:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198216 Bug ID: 198216 Summary: According to man page for pthread_cond_destroy it returns EBUSY error code, but it never does Product: Documentation Version: Latest Hardware: Any URL: https://www.freebsd.org/cgi/man.cgi?query=pthread_cond _destroy&apropos=0&sektion=3&manpath=FreeBSD+11-curren t&arch=default&format=html OS: Any Status: New Severity: Affects Many People Priority: --- Component: Documentation Assignee: freebsd-doc@FreeBSD.org Reporter: msiodelski@gmail.com I am using the following FreeBSD version: 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0 r279272: Wed Feb 25 12:27:40 CET 2015 built from the following svn branch: ^/releng/10.1 According to the man pages for the pthread_cond_destroy, it returns the following error codes: ERRORS The pthread_cond_destroy() function will fail if: [EINVAL] The value specified by cond is invalid. [EBUSY] The variable cond is locked by another thread. In the course of my testing I found that this function actually never returns EBUSY error code if the conditional variable is locked by another thread. Briefly looking at the pthread_cond_destroy implementation in /usr/src/lib/libthr/thread/thr_cond.c I don't see any checks for variable being locked by another thread: int _pthread_cond_destroy(pthread_cond_t *cond) { struct pthread_cond *cvp; int error = 0; if ((cvp = *cond) == THR_COND_INITIALIZER) error = 0; else if (cvp == THR_COND_DESTROYED) error = EINVAL; else { cvp = *cond; *cond = THR_COND_DESTROYED; /* * Free the memory allocated for the condition * variable structure: */ free(cvp); } return (error); } So it seems that one of the: documentation or the code is wrong. Some background about how it was tested. I am working on the Kea DHCP server implementation (kea.isc.org). One of our unit tests is exercising the scenario of trying to destroy the cond variable while it is locked by another thread. The expected behavior is that the pthread_cond_destroy fails with non-success status code, but it returns 0. However, this test uses C++ objects and infrastructure of our implementation and it hasn't been isolated as standalone test. If you find it useful to have such a standalone test which demonstrates the behavior, I can write one. For your convenience I am sending the locations of our source code where we run the test nested in our implementation: https://github.com/isc-projects/kea/blob/master/src/lib/util/threads/tests/condvar_unittest.cc (see the destroyWhileWait test). and the source code of the CondVar class under test: https://github.com/isc-projects/kea/blob/master/src/lib/util/threads/sync.cc Note that the destructor of the CondVar class calls the pthread_cond_destroy and then performs an assert that the status code is 0. For this test it should be non-zero and the process should die as expected by the test. But, it doesn't. Hope that helps. -- You are receiving this mail because: You are the assignee for the bug.