Re: [Mingw-w64-public] winpthread build with static edition

2011-07-26 Thread PcX
于 2011/7/23 20:43, NightStrike 写道: PcX, Is this still an issue, or did you figure it out in other threads? It also has the problem. I try to debug other thread: (gdb) thread 2 [Switching to thread 2 (Thread 5008.0x157

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-23 Thread NightStrike
PcX, Is this still an issue, or did you figure it out in other threads? On Mon, Jul 11, 2011 at 8:59 AM, PcX wrote: > 于 2011/7/11 19:13, Kai Tietz 写道: >> >> Another thing missing here is the use of lock as prefix ... > > I update to winpthreads svn 4271: > > this is a debug log > > GNU gdb (pcx3

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 19:13, Kai Tietz 写道: Another thing missing here is the use of lock as prefix ... I update to winpthreads svn 4271: this is a debug log GNU gdb (pcx32) 7.3.50.20110709 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 19:13, Kai Tietz 写道: > Another thing missing here is the use of lock as prefix Er.. I have to go out for some moment and sorry... -- Best Regards, PcX -- All of the data generated in your IT infrastructure i

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 19:11, Kai Tietz 写道: > 2011/7/11 PcX: >> 于 2011/7/11 19:02, Kai Tietz 写道: >>> So I don't understand here this ill-instruction failure you see. xadd >>> (which is used here underhood for .InterlockedDecrement is present >>> beginning with i486. see >>> http://asm.inightmare.org/opcodel

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
Another thing missing here is the use of lock as prefix ... -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats,

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 19:02, Kai Tietz 写道: >> >> So I don't understand here this ill-instruction failure you see.  xadd >> (which is used here underhood for .InterlockedDecrement is present >> beginning with i486.  see >> http://asm.inightmare.org/opcodelst/index.php?op=XADD > > It's very s

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 19:02, Kai Tietz 写道: > So I don't understand here this ill-instruction failure you see. xadd > (which is used here underhood for .InterlockedDecrement is present > beginning with i486. see > http://asm.inightmare.org/opcodelst/index.php?op=XADD It's very strange. I write : __

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 18:57, Kai Tietz 写道: >> >> What funny CPU you are using? It seems that xadd isn't supported by it. > > Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz 2.20 GHz > > -- > Best Regards, > PcX So I don't understand here this ill-instruction failure you see. xadd (which is use

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 18:57, Kai Tietz 写道: > What funny CPU you are using? It seems that xadd isn't supported by it. Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz 2.20 GHz -- Best Regards, PcX -- All of the data generated in your I

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
What funny CPU you are using? It seems that xadd isn't supported by it. Regards, Kai -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application perfor

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 18:38, Kai Tietz 写道: Well, it might be interesting to see here content of _pthread_tls variable. You can use in gdb the command 'print _pthread_tls' for this. What happens if you simple continue after this trace-point? (This is done by command 'c' in gdb). Here is: (gdb) p _pthread_

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
Well, it might be interesting to see here content of _pthread_tls variable. You can use in gdb the command 'print _pthread_tls' for this. What happens if you simple continue after this trace-point? (This is done by command 'c' in gdb). Kai 2011/7/11 PcX : > 于 2011/7/11 17:15, Kai Tietz 写道: >> >>

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 17:15, Kai Tietz 写道: You need to configure gcc with --enable-threads=posix to have full feature-set enabled for winpthread. Sorry, I'm not familiar with some gdb commands, so I type "step 1" here. This is the debug log: GNU gdb (pcx32) 7.3.50.20110709 Copyright (C) 2011 Free Sof

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 17:19, Kai Tietz 写道: > Yes, this is for sure something good, as it pre-initialize memory here. OK, I'll try again. I will go to dinner, and after that, I will email to you. Wait for my information please. Thanks. -- Best Regards, PcX -

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
Yes, this is for sure something good, as it pre-initialize memory here. Kai 2011/7/11 PcX : > 于 2011/7/11 17:15, Kai Tietz 写道: >> >> You need to >> configure gcc with --enable-threads=posix to have full feature-set >> enabled for winpthread.  Then you shouldn't have issues about gomp, >> too. > >

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 17:15, Kai Tietz 写道: > You need to > configure gcc with --enable-threads=posix to have full feature-set > enabled for winpthread. Then you shouldn't have issues about gomp, > too. And do I need change "team = gomp_malloc (size)" to "team = gomp_malloc_cleared (size)"? -- Best Regar

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
I see your issue. You are trying to use posix implementation of gomp with gthr-win32.h implementation of threading ... You need to configure gcc with --enable-threads=posix to have full feature-set enabled for winpthread. Then you shouldn't have issues about gomp, too. Regards, Kai 2011/7/11 K

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 16:58, Kai Tietz 写道: here does this line come from? I don't find '__ptr = TlsGetValue (__key);' in my source tree. Neither in winpthread, nor in crt-TLS code. As this log: GNU gdb (pcx32) 7.3.50.20110709 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL versi

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 16:06, Kai Tietz 写道: >> >> I mean change "team = gomp_malloc (size)" to "team = gomp_malloc_cleared >> (size)" > > I do that, but seem not be functional. > It's debug log. > It stops at 611      __ptr = TlsGetValue (__key); > Then it seems to enter an endless lopp. Wh

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 16:06, Kai Tietz 写道: I mean change "team = gomp_malloc (size)" to "team = gomp_malloc_cleared (size)" I do that, but seem not be functional. It's debug log. It stops at 611 __ptr = TlsGetValue (__key); Then it seems to enter an endless lopp. -- Best Regards, PcX debug.log De

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 14:15, Kai Tietz 写道: >> >> See in team.c the function gomp_new_team. Use here instead for 'team = >> gomp_malloc (size);' the following 'team = gomp_malloc_cleared (size);'. > > You mean change "team = gomp_malloc (size)" to "team = gomp_malloc_cleared > (size)", or af

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 14:15, Kai Tietz 写道: > See in team.c the function gomp_new_team. Use here instead for 'team = > gomp_malloc (size);' the following 'team = gomp_malloc_cleared (size);'. You mean change "team = gomp_malloc (size)" to "team = gomp_malloc_cleared (size)", or after ""team = gomp_malloc (

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 15:17, Kai Tietz 写道: > > could you test this modification and see > > You say the libgomp modification ? > I have to recompile gcc... > > -- > Best Regards, > PcX Well, for first step you need just to recompile libgomp (and possible dependent libraries). A complete bo

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 15:17, Kai Tietz 写道: could you test this modification and see You say the libgomp modification ? I have to recompile gcc... -- Best Regards, PcX -- All of the data generated in your IT infrastructure is ser

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread Kai Tietz
2011/7/11 PcX : > 于 2011/7/11 14:15, Kai Tietz 写道: >> >> So I looked a bit into libgomp's source code and I see that I might have >> found the cause for this crash. See in team.c the function gomp_new_team. >> Use here instead for 'team = gomp_malloc (size);' the following 'team = >> gomp_malloc_cl

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-11 Thread PcX
于 2011/7/11 14:15, Kai Tietz 写道: > So I looked a bit into libgomp's source code and I see that I might > have found the cause for this crash. See in team.c the function > gomp_new_team. Use here instead for 'team = gomp_malloc (size);' the > following 'team = gomp_malloc_cleared (size);'. This m

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
So I looked a bit into libgomp's source code and I see that I might have found the cause for this crash. See in team.c the function gomp_new_team. Use here instead for 'team = gomp_malloc (size);' the following 'team = gomp_malloc_cleared (size);'. This might be already the cause for this crash.

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
You might get a different break-point by pressing instead of Ctrl-C the Ctrl-Break key. You are seeing here the signal-catcher of windows about control-c's exception. You can switch to different threads via the 'tread ' command. For more details about using gdb you can use 'info gdb' or you can

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
This issue is cause by libgomp feeding pthread library with an old handle. IMHO this seems to be an issue of libgomp and not treating here failure-codes proper. But well, maybe you can find out here more details, so we could be able to work-a-round this issue. Regards, Kai 2011/7/10 PcX > 于 2

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread PcX
于 2011/7/10 18:30, Kai Tietz 写道: Ok, could you do a last test for attempt to fix this issue for winpthread? Rev 4269 Thanks in advance, Kai I update to 4269 It seems to fix the problem, but the run progress is not normal, and it seems to come int

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
Ok, could you do a last test for attempt to fix this issue for winpthread? Rev 4269 Thanks in advance, Kai -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive recor

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread PcX
于 2011/7/10 17:29, Kai Tietz 写道: > Sorry, but I will stop here further investigations as it seems to be a > bug somewhere else. Thanks. I will use pthread-win32 temporarily. -- Best Regards, PcX -- All of the data gene

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
Well, so it seems to be a bug in libgomp. To add here a sequence-list for valid objects within this library makes no sense, as it drains performance too much. It seems that libgomp stores internally pointer to internal objects and so invalid internal objects are passed. Sorry, but I will stop her

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread PcX
于 2011/7/10 16:44, Kai Tietz 写道: So, it might be a racing condition in destruction case and breaking of pending operations. So I addressed this at  revision 4267.  If this problem still happens, then it might be a bug in gomp. It also doesn't function...

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
So, it might be a racing condition in destruction case and breaking of pending operations. So I addressed this at revision 4267. If this problem still happens, then it might be a bug in gomp. Regards, Kai -- All of the d

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread PcX
于 2011/7/10 15:25, Kai Tietz 写道: Does it help to insert at line 90 of sem.c the check IsBadReadPtr (sv sizeof (*sv)) befor the check for sv->valid == DEAD_SEM?  if (!sem || (sv = *sem) == NULL || IsBadReadPtr (sv, sizeof (*sv)) || sv->valid == DEAD_SEM)

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread Kai Tietz
Hmm, it seems to me that omp destroys barriers and then try to continue to use them ... Does it help to insert at line 90 of sem.c the check IsBadReadPtr (sv sizeof (*sv)) befor the check for sv->valid == DEAD_SEM? Regards, Kai 2011/7/10 PcX > Hi, Kai Tietz > > I update to svn 4266, and th

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-10 Thread PcX
Hi, Kai Tietz     I update to svn 4266, and there is also the problem, but is different: -- Best Regards, PcX -- All of the data generated in your IT inf

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread PcX
于 2011/7/9 19:15, PcX 写道: 于 2011/7/9 18:36, Kai Tietz 写道: The potential fix for this is at rev 4265. I update to 4265, but it also has the problem: -- Best Regards, PcX This is more information: -- Best R

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread PcX
于 2011/7/9 18:36, Kai Tietz 写道: The potential fix for this is at rev 4265. I update to 4265, but it also has the problem: -- Best Regards, PcX -- All of the data generated in you

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread Kai Tietz
So, this backtrace was indeed interesting. Thanks for telling me my typo ... it should be indeed IsBadReadPtr. So I added a possible fix here in sem.c at revision 4265 for this. It is to be expected that you get in debugger still an exeption (as notice not a segfault itself). This is caused by I

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread PcX
于 2011/7/9 17:59, PcX 写道: 于 2011/7/9 17:50, PcX 写道: then all work well. I fix my result. It can run, but seem to enter an endless loop. -- Best Regards, PcX This is more information: -- Best

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread PcX
于 2011/7/9 17:50, PcX 写道: then all work well. I fix my result. It can run, but seem to enter an endless loop. -- Best Regards, PcX -- All of the data generated in your IT

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread PcX
于 2011/7/9 17:00, Kai Tietz 写道: Thanks, but a backtrace would be better (in gdb after break just type 'bt' and press enter.  Thanks. I type bt, and the out put: [New Thread 372.0x430] Program received signal SIGSEGV, Segmentation fault. 0x00

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-09 Thread Kai Tietz
Thanks, but a backtrace would be better (in gdb after break just type 'bt' and press enter. Anyway, I added a check here, which might be helpful, at revision 4263. It could fix your issue. Regards, Kai 2011/7/9 PcX > 于 2011/7/9 13:05, PcX 写道: > > I tried to debug winpthread, and I found

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread PcX
于 2011/7/9 13:05, PcX 写道:     I tried to debug winpthread, and I found the crash stopped at src/mutex.c:38 38 if (!m || !*m) And I tried to print the value of the *m (gdb) p *m Cannot access memory at address 0xbaadf019

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread PcX
Hi, all     I tried to debug winpthread, and I found the crash stopped at src/mutex.c:38 38 if (!m || !*m) -- Best Regards, PcX -- All of the data generated in yo

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread Kai Tietz
Thanks for the test-program. But as I don't have right now a gcc with gomp support, it would be more interesting for me to see the backtrace. Thanks in advance, Kai 2011/7/8 PcX > 于 2011/7/9 1:33, PcX 写道: > > Hi, all > > I built winpthread with "./configure --enable-static --disable-share

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread PcX
于 2011/7/9 1:33, PcX 写道: Hi, all     I built winpthread with "./configure --enable-static --disable-shared", and I use it to build gcc4.6.1 with "./configure --enable-libgomp --enable-static --disable-shared".     But when I buil

Re: [Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread Kai Tietz
Hmm, this might be an raising condition and not occuring in static version. Could you provide the back-trace to see here it comes from? (gdb command bt) Thanks in advance, Kai 2011/7/8 PcX > Hi, all > > I built winpthread with "./configure --enable-static --disable-shared", > and I use it

[Mingw-w64-public] winpthread build with static edition

2011-07-08 Thread PcX
Hi, all     I built winpthread with "./configure --enable-static --disable-shared", and I use it to build gcc4.6.1 with "./configure --enable-libgomp --enable-static --disable-shared".     But when I build a openmp program, the compiler and linker sta