Re: [musl] Possible PEBKAC or Bug in musl Semaphores and/or Mutexes

[Gavin Howard <gavin.d.howard@gmail.com>]

> 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