DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52O5rTmY2147175 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52O5rTmY2147175 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=vHimQw61 X-Recipient: archive-cygwin@delorie.com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 42E3B385AC22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1742795607; bh=4m4G3BGI8YKuswkuByhJ2Q4JaZ8IGOSV5sYBIKpdVTg=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=vHimQw61u1dj/+as99EmbFHBl/CR9xozTdPaq333WsT556hnLRSXvkR2uD28rwV2r kchFe+LArz97x0hCRMaQtwrjIgpYxOnryef+65Tfedvj00YL8Bsk6ps6/x5fE8R55Q FbPFAx/FufKkTBirQ4XRo0lKIV9yiHEQ+zLFKgus= X-Original-To: cygwin@cygwin.com Delivered-To: cygwin@cygwin.com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A34CF3858D33 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A34CF3858D33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1742795547; cv=none; b=JAkJQg1R30qnCaMVTmLbh3oYtCVnBuCrq7Z+ThGqOsE3FplDm6pdb84im6Yz08h8hlKaORYjHIKQRN4Yb/pEVFUJvCfL1DP1zlWeQqRsLso7nuIeUnBEzTgTeHEBz7v6Vh7oY4zh505Nb/eampHRiHRAig/I0/9+2xtzJxcSuVE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1742795547; c=relaxed/simple; bh=OVzpEcyJb4IAfjas4BqMsP0LOOQk6k/lkmhEiVXt9MA=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=PikOupkWCLLry/LkcLdWgbLq67lfv0vdURdKyJpZoittya3kjKqmtKyPMfcHiTG8LsL6saGTxZ3iQvk+TYD9KSModjH0rkIdwxp9sNCplz/+D7IQEbnvpOC9VIVQ7WzUMP55w7MS1qWjktr/2YFDT30c34YsTZ/6YCUGrOGG7bU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A34CF3858D33 Date: Mon, 24 Mar 2025 14:52:21 +0900 To: cygwin@cygwin.com Subject: Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key Message-Id: <20250324145221.25188bbb53d8ee7a8160e3ab@nifty.ne.jp> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com Sender: "Cygwin" On Sun, 23 Mar 2025 20:32:44 +0800 Yuyi Wang wrote: > It's a bug when I tried to run tests of Rust std lib. The standard > library of Rust tries to create a new pthread_key in the destructor of a > key created previously. Unfortunately, List::for_each locked the mutex > before, so List_insert method cannot lock the mutex again. > > I have searched though the POSIX docs and didn't find any words that one > should not call pthread_key_create in the destructor of a pthread_key. I > think it should be a bug of cygwin. Thanks for the report. I'll submit a patch to fix the issue. BTW, IIUC, the Rust compiler itself you worked on is not cygwin binary, but it generates cygwin binary. (I mean it is some kind of cross compiler.) Right? Rust compiler is coded by Rust, so is it possible to build Rust compiler itself by the cross-compiler? If so, the Rust compiler can be a cygwin- bynary. Are there something missing from cygwin to do that? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple