From nobody Sat Aug 06 20:55:45 2022 X-Original-To: threads@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M0ZVp535vz4Xr6q for ; Sat, 6 Aug 2022 20:55:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M0ZVp3y9kz3wSd for ; Sat, 6 Aug 2022 20:55:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4M0ZVp31tdzn59 for ; Sat, 6 Aug 2022 20:55:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 276KtkvC017293 for ; Sat, 6 Aug 2022 20:55:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 276KtkNm017292 for threads@FreeBSD.org; Sat, 6 Aug 2022 20:55:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 237195] pthread_mutex_unlock crash as unlocked mutex destroyed by signaled thread Date: Sat, 06 Aug 2022 20:55:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: longwitz@incore.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659819346; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1rmtcuxvshVOgPNZwi6oW50F/tjBglAAVJNCdgqmrdc=; b=DJ4t+Hgv4gdPjfremryRym3U00ZdsJsqAvbyDGqpC/Cc//G13LV3mZDjFBRUVANLHo+C25 FQ/IpAnc1smASeLsIOuuUFtcEBGnah1Abgs49z2J5E7X2GsGxuiNgo2KmebD1keI68T9ir 5HmY8/mOZkpGsH4H5Hfg/0Bs69IDubfGOqW4aA9YvK0n8aXXs8pGoFvZQZ2bq5nDy3LUJ8 z9mYJsqfEZq977kDGapIpcArsm9PjGccJXsy4qRY3nKB0KKBA1IuDJ7JZF6ybACpG1fw2U mWbeWe4MFAJ4xcpY/XIOYKwEXShYm0ZzvWuvTOmpBKl36Rsp++A50LLg87+gQg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659819346; a=rsa-sha256; cv=none; b=YE7FlNsWE0+L0Mp5Hu1EW2bj/j/GBMuE9KHKAh+jp2fMOgmicaWlIyCHIz77DJAKj4LLLC Q6Q73FNLvonRX5o1YIChq9jTPZy3+vG6Eyfu+Jxhy2yo9xm3ciwuki7Zrpu9nkxmbtdeMt 4lp6gDDFSLk76urbi+GIJJeQrglvE/oVZbOkJ8M5VlpFwfs6xu4gxNQIFPNvJtkhJ0efn6 aKvHbrbhY0MfD7BPwcw1VrXdHWENW3Q2NEuYpmZevSSMZnpgLIs8NOGZi3xhHCC2TexmNQ rCXKCjJlW4iTAoAiEibfXsJysIie9vlS5m3g9KE5xrolDr7u+ebLJftn/Egqeg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237195 --- Comment #11 from longwitz@incore.de --- The stack trace with samba given in comment #9 is an other problem because = tdb does never use the function pthread_mutex_destroy() for a mutex in a shared memory, only in local memory for checking the features of the lib= thr library. I hit the problem discussed in this bug report when I tried to migrate a st= able running IMAP server (cyrus-imapd25 + db48) from FreeBSD 10 to Fre eBSD 12 r371380. The configure step of db48 finds in V10: checking for mutexes... x86_64/gcc-assembly in V12: checking for mutexes... POSIX/pthreads/library/x86_64/gcc-assembly The difference is because FreeBSD 12 supports PTHREAD_PROCESS_SHARED. It co= mes out the berkeley db48 software is not compatibel with the share mu texes in our libthr. When an imap program (e.g. cyr_expire) is finished, db= 48 calls pthread_mutex_destroy() for all used mutexes. On the next try of the IMAP server or of another imap program to get a lock with pthread_mutex_lock() the error EINVAL is returned and the environment of be= rkel ey db is broken. Newer versions of berkeley db have the same problem. I can simple avoid the problem with a configure statement for db48 to force only the test-an d-set mutexes as in V10. I attach a test program mypshared.c that demonstrates the problem I see wit= h my IMAP server in V12. If mypshared is started on two or three termi nals then the problem with pthread_mutex_destroy() can be studied. If in the program the variable always_destroy is set to 0, then all started pr ograms run and stop without error, because only the last finishing program calls pthread_mutex_destroy(). With always_destroy =3D 1 there are two c ases when the first program comes to his end: 1. No one of the other programs has the lock. In this case the ending progr= am calls pthread_mutex_destroy() without error but the other programs get EINVAL at the next call to pthread_mutex_lock(). That is what I saw run= ning my IMAP server. 2. One of the other programs helds the lock. Then the ending program calling pthread_mutex_destroy() aborts with a message like Fatal error 'mutex 0x800698000 own 0x8001872a is on list 0x8006861a0 0x0' at line 154 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno =3D 0) This is caused by the call of mutex_assert_not_owned() at line 481 because _PTHREADS_INVARIANTS is set in the Makefile. Both cases are bad, the application can not work. With higher or lower values for UPPER_BOUND_(NO)LOCK in mypshared.c it is e= asy to get examples for both cases. My mutex is always on addr 0x80069 7000, but the error message gives 0x800698000. Instead of "0x8001872a" sometimes I see "own 0x1872a". The "first mutex problem" was solved with the commit for revision 297185. A program of an application must not check if it is the first program u sing a mutex, A simple call of pthread_mutex_init() is enough, the pthread library libthr is smart and handles this. Maybe the "last mutex proble m" can be solved too with a similar logic. pthread_mutex_destroy() should only destroy the m= utex if the caller is the last user of the mutex. And pthread_mutex_destroy() al= ways should return without errors like EBUSY. If a user is not the last one and calls pthread_mutex_destroy() the mutex should not be affected and the users state should be the same he had before calling pthread_mtx_init(). If we cannot solve the "last mutex problem" then there should be an option = to build the libthr without PTHREAD_PROCESS_SHARED. --=20 You are receiving this mail because: You are the assignee for the bug.=