r5491 removed some special handling of EINVAL from sem.c, which turned
out to cause something what looks like a period of busy waiting followed
by a deadlock in some code using pthreads. Code in question is a library
using ffmpeg as a pthreads caller, without using pthreads itself.
After git-bisecting this to r5491, and adding back the removed lines,
the error goes way.
I have to admit that I was too lazy to actually understand the code in question... I just bisected and added the lines back. I don't see any reason given why they were removed in the first place... Maybe they were removed in error?
I also am not currently set up to produce stacks and/or give simple steps-to-reproduce, unfortunately.
FWIW, here is some information about my stack:
GCC 4.8.2 cross-compiler on Debian lenny (self-compiled according to my Makefile):
$ i686-w64-mingw32-gcc -v
Using built-in specs.
Configured with: ../../gcc-4.8.2/configure --target=i686-w64-mingw32 --enable-languages=c,c++,objc,obj-c++ --disable-nls --disable-multilib --enable-lto --with-isl=/usr/local --with-cloog=/usr/local CC=gcc-4.7 CXX=g++-4.7 CXXCPP='g++-4.7 -E ' CFLAGS='-O3 -msse2 -mfpmath=sse -mtune=generic -funroll-loops -funswitch-loops -fomit-frame-pointer' CXXFLAGS='-O3 -msse2 -mfpmath=sse -mtune=generic -funroll-loops -funswitch-loops -fomit-frame-pointer'
Thread model: win32
gcc version 4.8.2 (GCC)
$ i686-w64-mingw32-as --version
GNU assembler (GNU Binutils) 2.23.2
configure line for winpthreads (trunk):
$ ../../mingw-w64/mingw-w64-libraries/winpthreads/configure --host=i686-w64-mingw32 --prefix=/usr/local/i686-w64-mingw32 --disable-shared CFLAGS="-O3 -mtune=generic"