[Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ruben Van Boxem
Hi,

As promised, I am investigating the shared libstdc++ std::thread problem
with winpthreads. Basically, a simple "Hello from thread" test program
throws an "Operation not permitted" std::system_error exception, which is
most likely a result from winpthreads setting errno to EPERM. Test program
below:

#include 
#include 

using namespace std;

void f()
{
cout << "hello from thread!" << endl;
}

int main()
{
thread t1(f);
thread t2(f);

t1.join();
t2.join();
}

Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
4.7.0-stdthread) you can easily see that when not compiling this with
"-static", the program throws abovementioned exception.

I did some looking into the issue, and came up with the following:
1. There are 16 occurrences of EPERM in winpthreads (although not all are
return codes I think), in pthreads-win32, there are only 6 discernable
usages. This might be due to less correctness in pthreads-win32, but the
difference is at the very least noticeable.
2. I recompiled winpthreads, disabling each EPERM usage on  per-file basis,
messing up correct functionality, but hoping to disrupt some pthreads error
to libstdc++ exception conversion, but nothing there had any effect.
3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
resulting in always throwing an exception. Strange enough, Google popped up
this reverse situation for GCC 4.6 and Debian/glibc:
http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem

Could it be that in the libstdc++ dll, this function __ghtread_active_p()
is inlined in the dll (so to speak) to always cause this exception being
thrown due to some incompatibility with the assumed semantics of inline and
dll's?

I'd see if building a libstdc++ dll with debug info helps, but frankly, dll
debug info has always been disappointing in comparison to Linux so debug
info.

Any thoughts on how to best proceed are much appreciated.

Ruben

PS: currently winpthreads is broken due to the recent pthread_time.h change:
In file included from
m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nanosleep'
m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'clock_nanosleep'
In file included from
m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'clock_getres'
m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'clock_gettime'
m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
error: expected '=', ',', ';', 'asm' or '__attribute__' before
'clock_settime'
I reincluded  for the time being in that file, working around
this error. I notified Kai of this on IRC, but he hasn't responded yet, so
I'm repeating it here for the record.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ozkan Sezer
On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
 wrote:
> Hi,
>
> As promised, I am investigating the shared libstdc++ std::thread problem
> with winpthreads. Basically, a simple "Hello from thread" test program
> throws an "Operation not permitted" std::system_error exception, which is
> most likely a result from winpthreads setting errno to EPERM. Test program
> below:
>
> #include 
> #include 
>
> using namespace std;
>
> void f()
> {
>     cout << "hello from thread!" << endl;
> }
>
> int main()
> {
>     thread t1(f);
>     thread t2(f);
>
>     t1.join();
>     t2.join();
> }
>
> Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
> 4.7.0-stdthread) you can easily see that when not compiling this with
> "-static", the program throws abovementioned exception.
>
> I did some looking into the issue, and came up with the following:
> 1. There are 16 occurrences of EPERM in winpthreads (although not all are
> return codes I think), in pthreads-win32, there are only 6 discernable
> usages. This might be due to less correctness in pthreads-win32, but the
> difference is at the very least noticeable.
> 2. I recompiled winpthreads, disabling each EPERM usage on  per-file basis,
> messing up correct functionality, but hoping to disrupt some pthreads error
> to libstdc++ exception conversion, but nothing there had any effect.
> 3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
> resulting in always throwing an exception. Strange enough, Google popped up
> this reverse situation for GCC 4.6 and Debian/glibc:
> http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
>
> Could it be that in the libstdc++ dll, this function __ghtread_active_p() is
> inlined in the dll (so to speak) to always cause this exception being thrown
> due to some incompatibility with the assumed semantics of inline and dll's?
>
> I'd see if building a libstdc++ dll with debug info helps, but frankly, dll
> debug info has always been disappointing in comparison to Linux so debug
> info.
>
> Any thoughts on how to best proceed are much appreciated.
>
> Ruben
>
> PS: currently winpthreads is broken due to the recent pthread_time.h change:
> In file included from
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nanosleep'
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'clock_nanosleep'
> In file included from
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> from m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'clock_getres'
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'clock_gettime'
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
> error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'clock_settime'
> I reincluded  for the time being in that file, working around
> this error. I notified Kai of this on IRC, but he hasn't responded yet, so
> I'm repeating it here for the record.

Rev. 4589 should fix it.

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ruben Van Boxem
2011/11/6 Ozkan Sezer 

> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>  wrote:
> > Hi,
> >
> > As promised, I am investigating the shared libstdc++ std::thread problem
> > with winpthreads. Basically, a simple "Hello from thread" test program
> > throws an "Operation not permitted" std::system_error exception, which is
> > most likely a result from winpthreads setting errno to EPERM. Test
> program
> > below:
> >
> > #include 
> > #include 
> >
> > using namespace std;
> >
> > void f()
> > {
> > cout << "hello from thread!" << endl;
> > }
> >
> > int main()
> > {
> > thread t1(f);
> > thread t2(f);
> >
> > t1.join();
> > t2.join();
> > }
> >
> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
> > 4.7.0-stdthread) you can easily see that when not compiling this with
> > "-static", the program throws abovementioned exception.
> >
> > I did some looking into the issue, and came up with the following:
> > 1. There are 16 occurrences of EPERM in winpthreads (although not all are
> > return codes I think), in pthreads-win32, there are only 6 discernable
> > usages. This might be due to less correctness in pthreads-win32, but the
> > difference is at the very least noticeable.
> > 2. I recompiled winpthreads, disabling each EPERM usage on  per-file
> basis,
> > messing up correct functionality, but hoping to disrupt some pthreads
> error
> > to libstdc++ exception conversion, but nothing there had any effect.
> > 3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
> > resulting in always throwing an exception. Strange enough, Google popped
> up
> > this reverse situation for GCC 4.6 and Debian/glibc:
> >
> http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
> >
> > Could it be that in the libstdc++ dll, this function
> __ghtread_active_p() is
> > inlined in the dll (so to speak) to always cause this exception being
> thrown
> > due to some incompatibility with the assumed semantics of inline and
> dll's?
> >
> > I'd see if building a libstdc++ dll with debug info helps, but frankly,
> dll
> > debug info has always been disappointing in comparison to Linux so debug
> > info.
> >
> > Any thoughts on how to best proceed are much appreciated.
> >
> > Ruben
> >
> > PS: currently winpthreads is broken due to the recent pthread_time.h
> change:
> > In file included from
> >
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> > from
> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> 'nanosleep'
> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> > 'clock_nanosleep'
> > In file included from
> >
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> > from
> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> > 'clock_getres'
> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> > 'clock_gettime'
> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> > 'clock_settime'
> > I reincluded  for the time being in that file, working around
> > this error. I notified Kai of this on IRC, but he hasn't responded yet,
> so
> > I'm repeating it here for the record.
>
> Rev. 4589 should fix it.
>

Wow, didn't notice the type :-/ Thanks!

>
>
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ruben Van Boxem
2011/11/6 Ruben Van Boxem 

> 2011/11/6 Ozkan Sezer 
>
>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>>  wrote:
>> > Hi,
>> >
>> > As promised, I am investigating the shared libstdc++ std::thread problem
>> > with winpthreads. Basically, a simple "Hello from thread" test program
>> > throws an "Operation not permitted" std::system_error exception, which
>> is
>> > most likely a result from winpthreads setting errno to EPERM. Test
>> program
>> > below:
>> >
>> > #include 
>> > #include 
>> >
>> > using namespace std;
>> >
>> > void f()
>> > {
>> > cout << "hello from thread!" << endl;
>> > }
>> >
>> > int main()
>> > {
>> > thread t1(f);
>> > thread t2(f);
>> >
>> > t1.join();
>> > t2.join();
>> > }
>> >
>> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
>> > 4.7.0-stdthread) you can easily see that when not compiling this with
>> > "-static", the program throws abovementioned exception.
>> >
>> > I did some looking into the issue, and came up with the following:
>> > 1. There are 16 occurrences of EPERM in winpthreads (although not all
>> are
>> > return codes I think), in pthreads-win32, there are only 6 discernable
>> > usages. This might be due to less correctness in pthreads-win32, but the
>> > difference is at the very least noticeable.
>> > 2. I recompiled winpthreads, disabling each EPERM usage on  per-file
>> basis,
>> > messing up correct functionality, but hoping to disrupt some pthreads
>> error
>> > to libstdc++ exception conversion, but nothing there had any effect.
>> > 3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
>> > resulting in always throwing an exception. Strange enough, Google
>> popped up
>> > this reverse situation for GCC 4.6 and Debian/glibc:
>> >
>> http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
>> >
>> > Could it be that in the libstdc++ dll, this function
>> __ghtread_active_p() is
>> > inlined in the dll (so to speak) to always cause this exception being
>> thrown
>> > due to some incompatibility with the assumed semantics of inline and
>> dll's?
>> >
>> > I'd see if building a libstdc++ dll with debug info helps, but frankly,
>> dll
>> > debug info has always been disappointing in comparison to Linux so debug
>> > info.
>> >
>> > Any thoughts on how to best proceed are much appreciated.
>> >
>> > Ruben
>> >
>> > PS: currently winpthreads is broken due to the recent pthread_time.h
>> change:
>> > In file included from
>> >
>> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> > from
>> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> 'nanosleep'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_nanosleep'
>> > In file included from
>> >
>> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> > from
>> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_getres'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_gettime'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_settime'
>> > I reincluded  for the time being in that file, working around
>> > this error. I notified Kai of this on IRC, but he hasn't responded yet,
>> so
>> > I'm repeating it here for the record.
>>
>> Rev. 4589 should fix it.
>>
>
> Wow, didn't notice the type :-/ Thanks!
>

Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
include):
libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/m/Development/Source/mingw-w64/experimental/winpthreads
-I/m/Development/Source/mingw-w64/experimental/winpthreads/include
-DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP -MF
src/.deps/libwinpthread_la-clock.Tpo -c
/m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
-DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
In file included from
m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
m:/Development/Source/mingw-w64/experimental/winpthreads/src/winpthread_internal.h:25:59:
error: unknown type name 'pthread_t'

Thanks,

Ruben


>>
>> --
>> RSA(R) Conference 2012
>> Sav

Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ozkan Sezer
On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
 wrote:
> 2011/11/6 Ruben Van Boxem 
>>
>> 2011/11/6 Ozkan Sezer 
>>>
>>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>>>  wrote:
>>> > Hi,
>>> >
>>> > As promised, I am investigating the shared libstdc++ std::thread
>>> > problem
>>> > with winpthreads. Basically, a simple "Hello from thread" test program
>>> > throws an "Operation not permitted" std::system_error exception, which
>>> > is
>>> > most likely a result from winpthreads setting errno to EPERM. Test
>>> > program
>>> > below:
>>> >
>>> > #include 
>>> > #include 
>>> >
>>> > using namespace std;
>>> >
>>> > void f()
>>> > {
>>> >     cout << "hello from thread!" << endl;
>>> > }
>>> >
>>> > int main()
>>> > {
>>> >     thread t1(f);
>>> >     thread t2(f);
>>> >
>>> >     t1.join();
>>> >     t2.join();
>>> > }
>>> >
>>> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
>>> > 4.7.0-stdthread) you can easily see that when not compiling this with
>>> > "-static", the program throws abovementioned exception.
>>> >
>>> > I did some looking into the issue, and came up with the following:
>>> > 1. There are 16 occurrences of EPERM in winpthreads (although not all
>>> > are
>>> > return codes I think), in pthreads-win32, there are only 6 discernable
>>> > usages. This might be due to less correctness in pthreads-win32, but
>>> > the
>>> > difference is at the very least noticeable.
>>> > 2. I recompiled winpthreads, disabling each EPERM usage on  per-file
>>> > basis,
>>> > messing up correct functionality, but hoping to disrupt some pthreads
>>> > error
>>> > to libstdc++ exception conversion, but nothing there had any effect.
>>> > 3. Due to number 2, I'm now assuming there's some bad code in
>>> > libstdc++,
>>> > resulting in always throwing an exception. Strange enough, Google
>>> > popped up
>>> > this reverse situation for GCC 4.6 and Debian/glibc:
>>> >
>>> > http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
>>> >
>>> > Could it be that in the libstdc++ dll, this function
>>> > __ghtread_active_p() is
>>> > inlined in the dll (so to speak) to always cause this exception being
>>> > thrown
>>> > due to some incompatibility with the assumed semantics of inline and
>>> > dll's?
>>> >
>>> > I'd see if building a libstdc++ dll with debug info helps, but frankly,
>>> > dll
>>> > debug info has always been disappointing in comparison to Linux so
>>> > debug
>>> > info.
>>> >
>>> > Any thoughts on how to best proceed are much appreciated.
>>> >
>>> > Ruben
>>> >
>>> > PS: currently winpthreads is broken due to the recent pthread_time.h
>>> > change:
>>> > In file included from
>>> >
>>> > m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>>> > from
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>>> >
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
>>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>>> > 'nanosleep'
>>> >
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
>>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>>> > 'clock_nanosleep'
>>> > In file included from
>>> >
>>> > m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>>> > from
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>>> >
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
>>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>>> > 'clock_getres'
>>> >
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
>>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>>> > 'clock_gettime'
>>> >
>>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
>>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>>> > 'clock_settime'
>>> > I reincluded  for the time being in that file, working
>>> > around
>>> > this error. I notified Kai of this on IRC, but he hasn't responded yet,
>>> > so
>>> > I'm repeating it here for the record.
>>>
>>> Rev. 4589 should fix it.
>>
>> Wow, didn't notice the type :-/ Thanks!
>
> Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
> include):
> libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
> -I/m/Development/Source/mingw-w64/experimental/winpthreads
> -I/m/Development/Source/mingw-w64/experimental/winpthreads/include
> -DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP -MF
> src/.deps/libwinpthread_la-clock.Tpo -c
> /m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
> -DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
> In file included from
> m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10

Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ruben Van Boxem
2011/11/6 Ozkan Sezer 

> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
>  wrote:
> > 2011/11/6 Ruben Van Boxem 
> >>
> >> 2011/11/6 Ozkan Sezer 
> >>>
> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
> >>>  wrote:
> >>> > Hi,
> >>> >
> >>> > As promised, I am investigating the shared libstdc++ std::thread
> >>> > problem
> >>> > with winpthreads. Basically, a simple "Hello from thread" test
> program
> >>> > throws an "Operation not permitted" std::system_error exception,
> which
> >>> > is
> >>> > most likely a result from winpthreads setting errno to EPERM. Test
> >>> > program
> >>> > below:
> >>> >
> >>> > #include 
> >>> > #include 
> >>> >
> >>> > using namespace std;
> >>> >
> >>> > void f()
> >>> > {
> >>> > cout << "hello from thread!" << endl;
> >>> > }
> >>> >
> >>> > int main()
> >>> > {
> >>> > thread t1(f);
> >>> > thread t2(f);
> >>> >
> >>> > t1.join();
> >>> > t2.join();
> >>> > }
> >>> >
> >>> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
> >>> > 4.7.0-stdthread) you can easily see that when not compiling this with
> >>> > "-static", the program throws abovementioned exception.
> >>> >
> >>> > I did some looking into the issue, and came up with the following:
> >>> > 1. There are 16 occurrences of EPERM in winpthreads (although not all
> >>> > are
> >>> > return codes I think), in pthreads-win32, there are only 6
> discernable
> >>> > usages. This might be due to less correctness in pthreads-win32, but
> >>> > the
> >>> > difference is at the very least noticeable.
> >>> > 2. I recompiled winpthreads, disabling each EPERM usage on  per-file
> >>> > basis,
> >>> > messing up correct functionality, but hoping to disrupt some pthreads
> >>> > error
> >>> > to libstdc++ exception conversion, but nothing there had any effect.
> >>> > 3. Due to number 2, I'm now assuming there's some bad code in
> >>> > libstdc++,
> >>> > resulting in always throwing an exception. Strange enough, Google
> >>> > popped up
> >>> > this reverse situation for GCC 4.6 and Debian/glibc:
> >>> >
> >>> >
> http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
> >>> >
> >>> > Could it be that in the libstdc++ dll, this function
> >>> > __ghtread_active_p() is
> >>> > inlined in the dll (so to speak) to always cause this exception being
> >>> > thrown
> >>> > due to some incompatibility with the assumed semantics of inline and
> >>> > dll's?
> >>> >
> >>> > I'd see if building a libstdc++ dll with debug info helps, but
> frankly,
> >>> > dll
> >>> > debug info has always been disappointing in comparison to Linux so
> >>> > debug
> >>> > info.
> >>> >
> >>> > Any thoughts on how to best proceed are much appreciated.
> >>> >
> >>> > Ruben
> >>> >
> >>> > PS: currently winpthreads is broken due to the recent pthread_time.h
> >>> > change:
> >>> > In file included from
> >>> >
> >>> >
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> >>> > from
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> >>> >
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> >>> > 'nanosleep'
> >>> >
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> >>> > 'clock_nanosleep'
> >>> > In file included from
> >>> >
> >>> >
> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
> >>> > from
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
> >>> >
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> >>> > 'clock_getres'
> >>> >
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> >>> > 'clock_gettime'
> >>> >
> >>> >
> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> >>> > 'clock_settime'
> >>> > I reincluded  for the time being in that file, working
> >>> > around
> >>> > this error. I notified Kai of this on IRC, but he hasn't responded
> yet,
> >>> > so
> >>> > I'm repeating it here for the record.
> >>>
> >>> Rev. 4589 should fix it.
> >>
> >> Wow, didn't notice the type :-/ Thanks!
> >
> > Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
> > include):
> > libtool: compile:  x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
> > -I/m/Development/Source/mingw-w64/experimental/winpthreads
> > -I/m/Development/Source/mingw-w64/experimental/winpthreads/include
> > -DIN_WINPTHREAD -Wall -g -O2 -MT src

Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception

2011-11-06 Thread Ozkan Sezer
On Sun, Nov 6, 2011 at 7:31 PM, Ruben Van Boxem
 wrote:
> 2011/11/6 Ozkan Sezer 
>>
>> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
>>  wrote:
>> > 2011/11/6 Ruben Van Boxem 
>> >>
>> >> 2011/11/6 Ozkan Sezer 
>> >>>
>> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>> >>>  wrote:
>> >>> > Hi,
>> >>> >
>> >>> > As promised, I am investigating the shared libstdc++ std::thread
>> >>> > problem
>> >>> > with winpthreads. Basically, a simple "Hello from thread" test
>> >>> > program
>> >>> > throws an "Operation not permitted" std::system_error exception,
>> >>> > which
>> >>> > is
>> >>> > most likely a result from winpthreads setting errno to EPERM. Test
>> >>> > program
>> >>> > below:
>> >>> >
>> >>> > #include 
>> >>> > #include 
>> >>> >
>> >>> > using namespace std;
>> >>> >
>> >>> > void f()
>> >>> > {
>> >>> >     cout << "hello from thread!" << endl;
>> >>> > }
>> >>> >
>> >>> > int main()
>> >>> > {
>> >>> >     thread t1(f);
>> >>> >     thread t2(f);
>> >>> >
>> >>> >     t1.join();
>> >>> >     t2.join();
>> >>> > }
>> >>> >
>> >>> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
>> >>> > 4.7.0-stdthread) you can easily see that when not compiling this
>> >>> > with
>> >>> > "-static", the program throws abovementioned exception.
>> >>> >
>> >>> > I did some looking into the issue, and came up with the following:
>> >>> > 1. There are 16 occurrences of EPERM in winpthreads (although not
>> >>> > all
>> >>> > are
>> >>> > return codes I think), in pthreads-win32, there are only 6
>> >>> > discernable
>> >>> > usages. This might be due to less correctness in pthreads-win32, but
>> >>> > the
>> >>> > difference is at the very least noticeable.
>> >>> > 2. I recompiled winpthreads, disabling each EPERM usage on  per-file
>> >>> > basis,
>> >>> > messing up correct functionality, but hoping to disrupt some
>> >>> > pthreads
>> >>> > error
>> >>> > to libstdc++ exception conversion, but nothing there had any effect.
>> >>> > 3. Due to number 2, I'm now assuming there's some bad code in
>> >>> > libstdc++,
>> >>> > resulting in always throwing an exception. Strange enough, Google
>> >>> > popped up
>> >>> > this reverse situation for GCC 4.6 and Debian/glibc:
>> >>> >
>> >>> >
>> >>> > http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
>> >>> >
>> >>> > Could it be that in the libstdc++ dll, this function
>> >>> > __ghtread_active_p() is
>> >>> > inlined in the dll (so to speak) to always cause this exception
>> >>> > being
>> >>> > thrown
>> >>> > due to some incompatibility with the assumed semantics of inline and
>> >>> > dll's?
>> >>> >
>> >>> > I'd see if building a libstdc++ dll with debug info helps, but
>> >>> > frankly,
>> >>> > dll
>> >>> > debug info has always been disappointing in comparison to Linux so
>> >>> > debug
>> >>> > info.
>> >>> >
>> >>> > Any thoughts on how to best proceed are much appreciated.
>> >>> >
>> >>> > Ruben
>> >>> >
>> >>> > PS: currently winpthreads is broken due to the recent pthread_time.h
>> >>> > change:
>> >>> > In file included from
>> >>> >
>> >>> >
>> >>> > m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> >>> > from
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >>> >
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
>> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> >>> > 'nanosleep'
>> >>> >
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
>> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> >>> > 'clock_nanosleep'
>> >>> > In file included from
>> >>> >
>> >>> >
>> >>> > m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> >>> > from
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >>> >
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
>> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> >>> > 'clock_getres'
>> >>> >
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
>> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> >>> > 'clock_gettime'
>> >>> >
>> >>> >
>> >>> > m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
>> >>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> >>> > 'clock_settime'
>> >>> > I reincluded  for the time being in that file, working
>> >>> > around
>> >>> > this error. I notified Kai of this on IRC, but he hasn't responded
>> >>> > yet,
>> >>> > so
>> >>> > I'm repeating it here for the record.
>> >>>
>> >>> Rev. 4589 should fix it.
>> >>
>> >> Wow, didn't notice the type :-/ Thanks!
>> >
>> > Argh.