#27 app using pthreads crashing in RtlpUnWaitCriticalSection()

[Anonymous]

Hi!

First of all, let me thank you for this really cool toolchain - you did a great job!

There is a problem unfortunately, when we try to use pthreads, though. As a test, we have written a very small app which basically uses pthreads to do some bogus calculations. Compiled with: "mingw-w64-bin_i686-cygwin-1.5.25-15_20100123" on a Win XP64 system.

When we launch it, it seems that it already crashes before reaching the main() function. From gdb:

Reading symbols from \\GUUL\server\devel\sdv\privat\rolf\win64\win64_test/w64_test1.exe...done.
(gdb) run
Starting program: \\GUUL\server\devel\sdv\privat\rolf\win64\win64_test/w64_test1.exe
[New Thread 1432.0xb44]

Program received signal SIGSEGV, Segmentation fault.
0x0000000077efbbfb in ntdll!RtlpUnWaitCriticalSection ()
from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x0000000077efbbfb in ntdll!RtlpUnWaitCriticalSection ()
from C:\WINDOWS\system32\ntdll.dll
#1 0x0000000000000000 in ?? ()
(gdb)

What is the current status of pthreads & mingw64?

FYI, we downloaded "libpthreadGC2.a" & "pthreadGC2.dll" from this website. Below are our compile/link options...

Again, thanks a lot for your support!

g++ -mwindows -mconsole -mthreads -w -g -O2 -DPTW32_STATIC_LIB test1.C -I/server/devel/extern/win64/pthreads/include -MD -c

g++ -mwindows -mconsole -mthreads --enable-auto-import test1.o -lsth2 -lMachineInfo -lhandler -lSCNTypes -lopengl32 -lglu32 -lwinmm -L/server/devel/extern/win64/pthreads/lib -lpthreadGC2 -lws2_32 -liphlpapi -o w64_test1.exe
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
Info: resolving std::cerr by linking to __imp___ZSt4cerr (auto-import/usr/local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.

[Nobody/Anonymous]

...ok, linking against "pthreadGC2.dll" only, solved our problem!

Seems' as if something weird is going on with "libpthreadGC2.a"...