From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29615 invoked from network); 15 Mar 2022 18:56:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Mar 2022 18:56:30 -0000 Received: (qmail 19999 invoked by uid 550); 15 Mar 2022 18:56:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19964 invoked from network); 15 Mar 2022 18:56:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wTqSYgc2N6IyEOZoOugeoILSDNeZWoF6ImTzt+VOzuo=; b=pSqt6KmrJSwQCVgTsCBZZaXCV4LHgKwXTQcqUohwQ/PVn56raZU0kkUDSyS0cVNY1U QEAvM8r+ZrpuxWFNcQ3Bnvv7bM7M7M7rhNyCEYMgWu76ehbPGXpjE2iWH5V7jxZBoVlQ 0vNASisvBiocWcb++PlZKg9W0wpoCD/Uo8qYesjQL0qvGkLr9PPEX7UI8m/CfUgjd2i9 RWHruuXxhdszIG5k+neHN8YL+FKJyoq0uzWbuegKL2I4poiD314DcjOhdVsGCJjpRbD/ 9Bq9wRWhc/gvwkHsx2B9uwDWiRL0hYk/i4Eau8EGanqHjvGgA6AxNQpG8K5z8eaKqZjA pFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wTqSYgc2N6IyEOZoOugeoILSDNeZWoF6ImTzt+VOzuo=; b=zoZSiiN8gSBr+6NDsyGttB/Z5M6/y1kzT+X9NCHx+Wxk6Gs3KpBsuwOWuKqq5WTNfq uUVaycpeJFA3NI8484clS3EC+2DoUmXObNBblcwCNTwsTUQB2lER9zAD/wyDG6UqIlRp SyMgPh9UnNof/7jkTzc2W5lvwnW+uPBxb8LvdBeAQIzZD4v+RxHVgCVHXgbqO9mn7IEb egmdCwUJqy/GAmBVUXH3UzEKxo2jwerbRBTEvn6dn3N2VMtzbHyuX1PLtgkhqzAa/x2C JzB7LyT1x4jcL+/qQeWlGgQ3+ZVFeWlShZs3pIZHNa57mi0d1yGnDWMqxmUXmxhaTaJ2 gAPQ== X-Gm-Message-State: AOAM532KmvqxqYZATh5IE8qeuqIlIzD47h1a+Dzv6I2Z6FlxCwIU0maj 7S3MZEW+DeUCmAG62SFVxXx3vWIS6UYetKkDk6UsybNxmEY= X-Google-Smtp-Source: ABdhPJy0zJhRI8RHVXKlv4domsvP50LcmSPlGFJWpOYnvtyhp7zXbtwER+rODwHB16uAY0gJZmiTNJ+BWrchAF1Tt/U= X-Received: by 2002:a05:6830:440a:b0:5c9:2563:b7d2 with SMTP id q10-20020a056830440a00b005c92563b7d2mr11226719otv.320.1647370574255; Tue, 15 Mar 2022 11:56:14 -0700 (PDT) MIME-Version: 1.0 References: <20220311202151.GW7074@brightrain.aerifal.cx> <20220312150132.GX7074@brightrain.aerifal.cx> <20220314162303.GZ7074@brightrain.aerifal.cx> In-Reply-To: <20220314162303.GZ7074@brightrain.aerifal.cx> From: Gavin Howard Date: Tue, 15 Mar 2022 12:55:38 -0600 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Possible PEBKAC or Bug in musl Semaphores and/or Mutexes > I might suggest a programming questions forum like Stack Overflow as a > more productive place to pursue this than the musl mailing list, since > this is pretty clearly not an actionable bug report (which would need > a complete test case you *can* publish that reproduces the purported > bug) and almost surely not related to any bug in musl. I am pretty sure that this is the right place and that it is a bug in musl. I spent the time to be able to make the code in question public and to create an easy reproducer for you so that you will have an actionable bug report. The code is at https://git.yzena.com/Yzena/Yc . Make sure you have CMake and Clang installed (I use Clang to test bootstrap on other platforms). Also be sure you have musl-gcc in /usr/local/musl/bin. Once you do, just run the following: ``` git clone https://git.yzena.com/Yzena/Yc.git cd Yc ./tools/rwlock_repro.sh -m ``` The rwlock_repro.sh script with the -m option will initialize the repo, build the build system using the musl-gcc, and then repeatedly run the build system on itself until some error happens. With this setup, I have been able to get it to show that more than one thread is allowed into the write lock critical section simultaneously, and this usually happens within two minutes with an average of about a minute. If it does happen, you should see a message like this: ``` Panic: More than one thread in the critical section Source: /home/gavin/Yc2/src/rig/build.c:555 Function: rig_searchPath() ``` This happens because there is a global variable that is incremented by threads when they enter that critical section and decremented when they leave, and that is the only place the global is used. (It's just for testing this.) Yet, sometimes, threads will find that it is greater than 1, which means that more than one thread is in that critical section. Even if there are bugs in my code, I'm pretty sure that is not supposed to happen with musl's read/write locks. Then again, I could be wrong; if I am wrong about what is supposed to happen with musl's rwlocks, please let me know. I tested this with musl 1.2.2 and the latest master as of last night. And this is on an AMD Ryzen Threadripper 1900X x86_64, if that helps. Gavin Howard