x264 MinGW/GCC 4.8.0 crash [solved]

[LoRd_MuldeR]

Anybody tried compiling x264 with MinGW/GCC 4.8.0?
x32-4.8.0-release-posix-sjlj-rev1.7z (http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-posix/sjlj/x32-4.8.0-release-posix-sjlj-rev1.7z/download)

Just did a plain "./configure + make" build, but crashes for me right away with:
(gdb) run
Starting program: d:\Sandbox\x264\build\x264_src\x264.exe --crf 20 --output test.mkv E:/Test.avs

[...]

Program received signal SIGSEGV, Segmentation fault.
0x759c79c8 in msvcrt!memcmp () from C:\Windows\syswow64\msvcrt.dll
(gdb) bt
#0 0x759c79c8 in msvcrt!memcmp () from C:\Windows\syswow64\msvcrt.dll
#1 0x004a303c in x264_cqm_init ()

Note: I also tried to make a Debug build, but it didn't crash.

I have built other stuff, like mpg123, with the very same MinGW/GCC release without any problems...

Any ideas? :confused:

[MasterNobody]

LoRd_MuldeR
You will need this https://github.com/DarkShikari/x264-devel/commit/e0625fe8f43c90eb2c91ee5164d60a0b2a97cbd9 or configure it with "--extra-cflags=-fno-aggressive-loop-optimizations".

[LoRd_MuldeR]

Thanks for the pointer, I will try that!

[LoRd_MuldeR]

Okay, with the suggested compiler flag it doesn't crash anymore.

But I noticed that the resulting binary runs very slow (less the 1 fps), though CPU load is high. Seems to be related to threading, as with "--threads 1" speeds are back to normal (~16 fps).

Check this one:
http://www.mediafire.com/file/pey68anxzwlik4z/x264_r2274_mingw480_1.rar

[EDIT]

Recompiled with "--enable-win32thread" and now the issue seems to be resolved. Now I get around 43 fps with 6 threads. Something with PThread and MinGW 4.8.0 seems to be fishy :o

[rogerdpack]

Thank you, using the compiler flag worked here.
(as a note to LoRd_MuldeR, the slow cpu issues for me typically mean I'm using winpthreads, whereas pthreads-win32 work ok do you think this is your scenario at all?).

[LoRd_MuldeR]

I used the PThreads that was included with current MinGW/GCC 4.8.0, from MinGW-Builds project. It comes in two flavors "Posix" and "Win32" threads. I tried both, but same issue :rolleyes:

Could try to compile my own pthreads-win32 library next. I usually prefer to have the PThreads lib compiled in statically anyway...

[Ajaja2005]

I use MinGW-Builds for compiling ffmpeg too (x32-4.8.0-release-posix-sjlj-rev1.7z and x64-4.8.0-release-posix-seh-rev1.7z). Threads (with pthreads ) works fine. But I do not use precompilied MinGW-Builds pthread library, I rebuild it by myself (statically).

[LoRd_MuldeR]

Okay, I now have compiled my own static PThreads library with MinGW 4.8.0, using the sources from here:
http://sourceware.org/pthreads-win32/

Now x264 works fine, even when compiled with "posix" threads! :)

Notes: Just replacing the "libpthread.a" and "libwinpthread.a" that shipped with MinGW-Builds with my own one didn't work. It compiled, but binary crashed right away. To make it work, I also head to replace the header files ("pthread.h", "sched.h" and "semaphore.h") with the ones from sourceware.org. But I had to keep the "pthread_time.h", which sourceware.org doesn't have. Finally I needed two copies of my own static PThreads lib, "libpthread.a" and "libpthreadGC2.a". Without the former, I get "No working C compiler found" and without the latter x264 doesn't enable "posix" threads. That's much more hackery than I thought I would need...

Is there any reason to not just stick with "win32" threads for x264 ???

[Ajaja2005]

Notes: Just replacing the "libpthread.a" and "libwinpthread.a" that shipped with MinGW-Builds with my own one didn't work. It compiled, but binary crashed right away. To make it work, I also head to replace the header files ("pthread.h", "sched.h" and "semaphore.h") with the ones from sourceware.org. But I had to keep the "pthread_time.h", which sourceware.org doesn't have. Finally I needed two copies of my own static PThreads lib, "libpthread.a" and "libpthreadGC2.a". Without the former, I get "No working C compiler found" and without the latter x264 doesn't enable "posix" threads. That's much more hackery than I thought I would need...
Wow. I just removed libpthread.dll.a and libwinpthread.dll.a from mingw-builds, and rebuild pthread:
cd pthreads-w32-2-9-1-release
make clean GC-static
cp libpthreadGC2.a ${mingw_prefix}/lib/libpthread.a
cp pthread.h sched.h semaphore.h ${mingw_prefix}/include
and x264:

cd x264
./configure --enable-static --host=$host --prefix=$mingw_prefix
--extra-cflags="-DPTW32_STATIC_LIB -fno-aggressive-loop-optimizations" || exit 1
make install || exit 1


and ffmpeg with --disable-w32threads --extra-cflags=-DPTW32_STATIC_LIB

works fine

[qyot27]

Okay, I now have compiled my own static PThreads library with MinGW 4.8.0, using the sources from here:
http://sourceware.org/pthreads-win32/

Now x264 works fine, even when compiled with "posix" threads! :)

Notes: Just replacing the "libpthread.a" and "libwinpthread.a" that shipped with MinGW-Builds with my own one didn't work. It compiled, but binary crashed right away. To make it work, I also head to replace the header files ("pthread.h", "sched.h" and "semaphore.h") with the ones from sourceware.org. But I had to keep the "pthread_time.h", which sourceware.org doesn't have. Finally I needed two copies of my own static PThreads lib, "libpthread.a" and "libpthreadGC2.a". Without the former, I get "No working C compiler found" and without the latter x264 doesn't enable "posix" threads. That's much more hackery than I thought I would need...

Is there any reason to not just stick with "win32" threads for x264 ???
pthread_time.h shouldn't be necessary; that sounds like there's some other header trying to pull it in that shouldn't be there (maybe an artifact of winpthreads?). The headers supplied should always match the lib, as winpthreads and pthreads-w32 most likely differ in some regard. It might also be an issue that if they are using pthreads-w32, it's a really old version before the autostatic patch was submitted, in which case it needs to be updated anyway. I actually fetch it from CVS rather than use the point releases; I also cross-compile from Ubuntu, and am waiting until installing 13.04 to update to GCC 4.8.0 from 4.7.2, but I doubt that has much bearing (unless it's something in the particular MinGW build or a 4.8.0 problem - I did use 4.8.0's prerelease several months ago and didn't experience any problems).

The thing about needing both libpthread.a and libpthreadGC2.a is more a limitation of the MinGW environment, I think. I've always gone with compiling pthreads-w32 myself rather than relying on the supplied one, and copying libpthreadGC2.a to libpthread.a has always been necessary. Probably has something to do with GCC's -pthread flag, while the projects themselves may actually try to look for libpthreadGC2 explicitly. x264 doesn't need the -DPTW32_STATIC_LIB flag passed to it manually by the user, although ffmpeg does.


The simple reason for not sticking with win32 threads is that A) I believe support for win32 threads was added much much later than pthreads (since pthreads is the standard library on *nix, so cross-platform support gets priority), and B) if you're using x264 in a larger project that pulls in other external libraries (like ffmpeg or mplayer/mplayer2/mpv), the threading library has to be the same for all of them - you can't mix-and-match. Some of those other external libraries don't support win32 threads, only pthreads. This is also true if pulling lavf and ffms2 into x264.

[LoRd_MuldeR]

Just wanted to add that "pthreads.h" from pthreads-w32 includes the "time.h" that ships with MinGW. And that one, in turn, includes "pthread_time.h", which isn't included with pthreads-w32, but shipped with MinGW (probably as part of winpthreads). First I removed all pthread-related header files that shipped with MinGW in order to avoid conflicts. Then I realized at least "pthread_time.h" needs to stay.

And of course you are right. The header files always need to match the lib. Simply didn't know that winpthreads and pthread-win32 are not fully compatible. Actually I expected the functions, data structures and constants of PThreads are consistent across all implementations - at least within one platform. Obviously they are not ;)

(BTW: Anybody knows why x264 performs so bad with winpthreads?)