Can you reproduce this threading bug?

[Antonio Corbi]

On Friday, 14 June 2019 at 18:41:41 UTC, FeepingCreature wrote:
> Happens for me at home too, with ldc2-1.11 on 4.14.111.
>
> I think with the Mac user reporting in, we can exclude a kernel 
> or glibc issue. Damn.

Using Arch Linux:

Linux hal9000 5.1.9-zen1-1-zen #1 ZEN SMP PREEMPT Tue Jun 11 
16:19:25 UTC 2019 x86_64 GNU/Linux

And dmd:
dmd --version
DMD64 D Compiler v2.086.0


Compiling with "dmd -g" and running the same loop but inside gdb 
(while true; do gdb -ex run -ex q ./ttest || break; done), this 
is the stack trace I get:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff7b1c700 (LWP 16006)]

Thread 2 "ttest" received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7ffff7b1c700 (LWP 16006)]
0x00007ffff7f6708a in __lll_unlock_wake () from 
/usr/lib/libpthread.so.0
A debugging session is active.

	Inferior 1 [process 15984] will be killed.

Quit anyway? (y or n) n
Not confirmed.
(gdb) bt
#0  0x00007ffff7f6708a in __lll_unlock_wake () from 
/usr/lib/libpthread.so.0
#1  0x00007ffff7f61a66 in __pthread_mutex_unlock_usercnt () from 
/usr/lib/libpthread.so.0
#2  0x000055555559083d in 
_D4core4sync5mutex5Mutex__T14unlock_nothrowTCQBrQBpQBnQBkZQBfMFNbNiNeZv ()
#3  0x000055555558f78f in 
_D4core6thread6Thread3addFNbNiCQBdQBbQxbZv ()
#4  0x00005555555a0088 in thread_entryPoint ()
#5  0x00007ffff7f5da92 in start_thread () from 
/usr/lib/libpthread.so.0
#6  0x00007ffff7d1ccd3 in clone () from /usr/lib/libc.so.6

Hope this helps.
Antonio