See the attached code. It compiles "fine" everywhere, but the resulting binary crashes in some situations:
It runs fine on all compilers on Linux; it runs fine on all versions of clang on FreeBSD and on GCC-4.9 on FreeBSD.
With GCC>=5 (including current 8-snapshot) the program crashes after 5 (sometimes 6) iterations. This may depend on the hardware, I can't say for sure. It is also strange how it is only triggered after multiple iterations.
The problem must have been introduced in the last months, I know for sure that it did not happen in June. However it seems strange that it affects all GCCs down to version 5. Maybe something that was backported?
I am CCing FreeBSD's port maintainer in case something happened on the packaging side of things.

https://gcc.gnu.org/bugs/
What we need:
...
- the complete command line that triggers the bug;
Are you linking to libpthread?
Where does it crash?
(In reply to Hannes Hauswedell from comment #0)
> The problem must have been introduced in the last months, I know for sure
> that it did not happen in June. However it seems strange that it affects all
> GCCs down to version 5. Maybe something that was backported?
Nope.
The code is largely the same for GNU/Linux and FreeBSD, and I'm not aware of any problems in it, and TSan doesn't show any, which suggests a problem in the FreeBSD pthreads implementation.
I do recall something in FreeBSD's pthreads impl being non-conforming, where the static PTHREAD_MUTEX_INITIALIZER (or maybe PTHREAD_COND_INITIALIZER) creates an invalid object that then requires dynamic initialization on the first use. There could be a race in that code (or I could be totally misremembering).

(In reply to Hannes Hauswedell from comment #4)
> The crash happens when calling .joinable(). If we skip the joinable check it
> crashes on .join().
That's not very precise. Calling it where? From the destructor? It doesn't make sense anyway, since joinable() just compares two pthread_t values for equality. No pointers are dereferenced.
Could we get a stack trace please?

(In reply to Andreas Tobler from comment #12)
> Will soon commit a fix, for gcc6/7/8 on FreeBSD > 9.3. Older gcc's and OS
> releases will not be supported by this fix.
Thanks a lot!
But is there no chance of getting a fix for gcc5? Not even via patch in the FreeBSD port (if not doable via gcc5 trunk)?
Because we would need to selectively disable gcc5 then (while gcc49 and >5 would still work which is kind of akward).

The gcc5 branch is closed, so I can not commit there. In the ports tree we're on gcc6 as default gcc. We still can build gcc5. I certainly can talk to Gerald to make an exception or whatever and patch the gcc5 port.