* Memory Barriers at pthread using CYGWIN
@ 2023-06-08 14:29 Mümin A.
2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-06-09 1:44 ` Duncan Roe
0 siblings, 2 replies; 12+ messages in thread
From: Mümin A. @ 2023-06-08 14:29 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 140 bytes --]
Hi,
I wrote a simple test for pthread_barrier_wait. it won't work as expected.
result should be
r1 = 1, r2 = 1
Thanks,
Mümin
[-- Attachment #2: CMakelists.txt --]
[-- Type: text/plain, Size: 295 bytes --]
cmake_minimum_required(VERSION 3.26)
project(test)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_definitions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112)
add_executable(test main.cpp)
target_link_libraries(test pthread)
[-- Attachment #3: main.cpp --]
[-- Type: text/plain, Size: 738 bytes --]
#include <stdio.h>
#include <pthread.h>
int x = 0;
int y = 0;
int r1 = 0;
int r2 = 0;
pthread_barrier_t barrier;
void* thread1(void* arg) {
y = 1;
pthread_barrier_wait(&barrier); // Memory barrier
r1 = x;
return NULL;
}
void* thread2(void* arg) {
x = 1;
pthread_barrier_wait(&barrier); // Memory barrier
r2 = y;
return NULL;
}
int main() {
pthread_t t1, t2;
pthread_barrier_init(&barrier, NULL, 2);
pthread_create(&t1, NULL, thread1, NULL);
pthread_create(&t2, NULL, thread2, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
printf("r1 = %d, r2 = %d\n", r1, r2);
pthread_barrier_destroy(&barrier);
return 0;
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN
2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A.
@ 2023-06-08 14:37 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-06-08 22:58 ` Mümin A.
2023-06-09 1:44 ` Duncan Roe
1 sibling, 1 reply; 12+ messages in thread
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2023-06-08 14:37 UTC (permalink / raw)
To: Mümin A., cygwin
> result should be
>
> r1 = 1, r2 = 1
>
And what was the result you saw?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN
2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
@ 2023-06-08 22:58 ` Mümin A.
2023-06-09 0:19 ` Kevin Schnitzius
2023-06-09 0:22 ` Takashi Yano
0 siblings, 2 replies; 12+ messages in thread
From: Mümin A. @ 2023-06-08 22:58 UTC (permalink / raw)
To: Lavrentiev, Anton (NIH/NLM/NCBI) [C], cygwin
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
r1=0 and r2=0
That is my result with Cygwin on windows. It’s false.
When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false.
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] <lavr@ncbi.nlm.nih.gov>
Sent: Thursday, June 8, 2023 5:37:31 PM
To: Mümin A. <muminaydin06@gmail.com>; cygwin@cygwin.com <cygwin@cygwin.com>
Subject: RE: [EXTERNAL] Memory Barriers at pthread using CYGWIN
> result should be
>
> r1 = 1, r2 = 1
>
And what was the result you saw?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [EXTERNAL] Memory Barriers at pthread using CYGWIN
2023-06-08 22:58 ` Mümin A.
@ 2023-06-09 0:19 ` Kevin Schnitzius
2023-06-09 0:22 ` Takashi Yano
1 sibling, 0 replies; 12+ messages in thread
From: Kevin Schnitzius @ 2023-06-09 0:19 UTC (permalink / raw)
To: cygwin
On Thursday, June 8, 2023 at 06:59:53 PM EDT, Mümin A. via Cygwin <cygwin@cygwin.com> wrote:
>
> r1=0 and r2=0
> That is my result with Cygwin on windows. It’s false.
>
> When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false.
> cmake .
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.26 or higher is required. You are running version 3.25.3
> g++ main.cpp
>./a
r1 = 1, r2 = 1
Kevin
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-08 22:58 ` Mümin A.
2023-06-09 0:19 ` Kevin Schnitzius
@ 2023-06-09 0:22 ` Takashi Yano
1 sibling, 0 replies; 12+ messages in thread
From: Takashi Yano @ 2023-06-09 0:22 UTC (permalink / raw)
To: cygwin; +Cc: Mümin A.
On Thu, 8 Jun 2023 22:58:59 +0000
Mümin A. wrote:
> r1=0 and r2=0
> That is my result with Cygwin on windows. It’s false.
>
> When I compiled with gcc. The result is correct but when I use lasted Cygwin gcc in windows 10. The result is false.
I cannot reproduce your problem.
If I compile main.cpp with 'g++ main.cpp', a.exe outputs
r1 = 1, r2 = 1
If I use cmake, I get an error message:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.26 or higher is required. You are running version 3.25.3
My environment is:
cygwin 3.4.6
g++ (GCC) 11.4.0
cmake version 3.25.3
all packages are updated.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A.
2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
@ 2023-06-09 1:44 ` Duncan Roe
1 sibling, 0 replies; 12+ messages in thread
From: Duncan Roe @ 2023-06-09 1:44 UTC (permalink / raw)
To: cygwin
On Thu, Jun 08, 2023 at 05:29:59PM +0300, cygwin wrote:
> Hi,
>
> I wrote a simple test for pthread_barrier_wait. it won't work as expected.
>
> result should be
>
> r1 = 1, r2 = 1
>
> Thanks,
> Mümin
> cmake_minimum_required(VERSION 3.26)
>
> project(test)
>
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_CXX_EXTENSIONS OFF)
>
>
> add_definitions(-D__POSIX_VISIBLE=200112 -D_POSIX_C_SOURCE=200112)
>
> add_executable(test main.cpp)
>
> target_link_libraries(test pthread)
> #include <stdio.h>
> #include <pthread.h>
>
> int x = 0;
> int y = 0;
> int r1 = 0;
> int r2 = 0;
>
> pthread_barrier_t barrier;
>
> void* thread1(void* arg) {
> y = 1;
> pthread_barrier_wait(&barrier); // Memory barrier
> r1 = x;
> return NULL;
> }
>
> void* thread2(void* arg) {
> x = 1;
> pthread_barrier_wait(&barrier); // Memory barrier
> r2 = y;
> return NULL;
> }
>
> int main() {
> pthread_t t1, t2;
>
> pthread_barrier_init(&barrier, NULL, 2);
>
> pthread_create(&t1, NULL, thread1, NULL);
> pthread_create(&t2, NULL, thread2, NULL);
>
> pthread_join(t1, NULL);
> pthread_join(t2, NULL);
>
> printf("r1 = %d, r2 = %d\n", r1, r2);
>
> pthread_barrier_destroy(&barrier);
>
> return 0;
> }
WFFM (compiled as a C program)
Cheers ... Duncan.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-22 11:48 ` Corinna Vinschen
@ 2023-06-22 23:49 ` Takashi Yano
0 siblings, 0 replies; 12+ messages in thread
From: Takashi Yano @ 2023-06-22 23:49 UTC (permalink / raw)
To: cygwin
On Thu, 22 Jun 2023 13:48:53 +0200
Corinna Vinschen wrote:
> On Jun 22 19:19, Takashi Yano via Cygwin wrote:
> > Any suggestions?
> >
> > On Tue, 20 Jun 2023 21:53:00 +0900
> > Takashi Yano wrote:
> > > I looked into this problem, and I think this is a problem regarding
> > > _my_tls initialization order, so far. This seems to happen in LDAP
> > > environment.
> > >
> > > My assumption is:
> > >
> > > If the program is the first program which load cygwin1.dll, ldap
> > > connection seems to be made before pthread::init_mainthread().
> > > In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or
> > > cyg_ldap::next_page() calls cygwait() in which pthread::self()
> > > is called.
> > >
> > > Then, _my_tls.tid is initialized with null_pthread, therefore,
> > > _my_tls.tid is not set in pthread::init_mainthread().
> > >
> > > This causes pthread_join() failure at:
> > > winsup/cygwin/thread.cc: line 2196
> > > if (!is_good_object (&joiner))
> > > return EINVAL;
> > >
> > >
> > > The first idea to fix this issue is remove set_tls_self_pointer()
> > > call from pthread::self().
> > >
> > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > > index 5c1284a93..a0f2d5546 100644
> > > --- a/winsup/cygwin/thread.cc
> > > +++ b/winsup/cygwin/thread.cc
> > > @@ -392,10 +392,7 @@ pthread::self ()
> > > {
> > > pthread *thread = _my_tls.tid;
> > > if (!thread)
> > > - {
> > > - thread = pthread_null::get_null_pthread ();
> > > - thread->set_tls_self_pointer ();
> > > - }
> > > + thread = pthread_null::get_null_pthread ();
> > > return thread;
> > > }
> > >
> > >
> > > The secnd approach is to re-initialize _my_tls.tid in
> > > pthread::init_mainthread() if _my_tls.tid is null_pthread.
> > >
> > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > > index 5c1284a93..f614e01c4 100644
> > > --- a/winsup/cygwin/thread.cc
> > > +++ b/winsup/cygwin/thread.cc
> > > @@ -364,7 +364,7 @@ void
> > > pthread::init_mainthread ()
> > > {
> > > pthread *thread = _my_tls.tid;
> > > - if (!thread)
> > > + if (!thread || thread == pthread_null::get_null_pthread ())
> > > {
> > > thread = new pthread ();
> > > if (!thread)
> > >
> > >
> > > Which is the better approach, do you think?
> > > Or any other idea?
>
> The second approach looks good to me. There was a reason to call
> set_tls_self_pointer from pthread::self, I guess. Resetting in
> init_mainthread should have the least potential for side-effects.
Thanks. I submitted the patch to cygwin-patches@cygwin.com.
Please let me know if I can push it.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-22 10:19 ` Takashi Yano
@ 2023-06-22 11:48 ` Corinna Vinschen
2023-06-22 23:49 ` Takashi Yano
0 siblings, 1 reply; 12+ messages in thread
From: Corinna Vinschen @ 2023-06-22 11:48 UTC (permalink / raw)
To: Takashi Yano; +Cc: cygwin
On Jun 22 19:19, Takashi Yano via Cygwin wrote:
> Any suggestions?
>
> On Tue, 20 Jun 2023 21:53:00 +0900
> Takashi Yano wrote:
> > I looked into this problem, and I think this is a problem regarding
> > _my_tls initialization order, so far. This seems to happen in LDAP
> > environment.
> >
> > My assumption is:
> >
> > If the program is the first program which load cygwin1.dll, ldap
> > connection seems to be made before pthread::init_mainthread().
> > In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or
> > cyg_ldap::next_page() calls cygwait() in which pthread::self()
> > is called.
> >
> > Then, _my_tls.tid is initialized with null_pthread, therefore,
> > _my_tls.tid is not set in pthread::init_mainthread().
> >
> > This causes pthread_join() failure at:
> > winsup/cygwin/thread.cc: line 2196
> > if (!is_good_object (&joiner))
> > return EINVAL;
> >
> >
> > The first idea to fix this issue is remove set_tls_self_pointer()
> > call from pthread::self().
> >
> > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > index 5c1284a93..a0f2d5546 100644
> > --- a/winsup/cygwin/thread.cc
> > +++ b/winsup/cygwin/thread.cc
> > @@ -392,10 +392,7 @@ pthread::self ()
> > {
> > pthread *thread = _my_tls.tid;
> > if (!thread)
> > - {
> > - thread = pthread_null::get_null_pthread ();
> > - thread->set_tls_self_pointer ();
> > - }
> > + thread = pthread_null::get_null_pthread ();
> > return thread;
> > }
> >
> >
> > The secnd approach is to re-initialize _my_tls.tid in
> > pthread::init_mainthread() if _my_tls.tid is null_pthread.
> >
> > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > index 5c1284a93..f614e01c4 100644
> > --- a/winsup/cygwin/thread.cc
> > +++ b/winsup/cygwin/thread.cc
> > @@ -364,7 +364,7 @@ void
> > pthread::init_mainthread ()
> > {
> > pthread *thread = _my_tls.tid;
> > - if (!thread)
> > + if (!thread || thread == pthread_null::get_null_pthread ())
> > {
> > thread = new pthread ();
> > if (!thread)
> >
> >
> > Which is the better approach, do you think?
> > Or any other idea?
The second approach looks good to me. There was a reason to call
set_tls_self_pointer from pthread::self, I guess. Resetting in
init_mainthread should have the least potential for side-effects.
Thanks,
Corinna
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-20 12:53 ` Takashi Yano
@ 2023-06-22 10:19 ` Takashi Yano
2023-06-22 11:48 ` Corinna Vinschen
0 siblings, 1 reply; 12+ messages in thread
From: Takashi Yano @ 2023-06-22 10:19 UTC (permalink / raw)
To: cygwin
Any suggestions?
On Tue, 20 Jun 2023 21:53:00 +0900
Takashi Yano wrote:
> On Sat, 10 Jun 2023 13:08:04 +0900 (JST)
> Takashi Yano wrote:
> > "M?min A." wrote:
> > > //windows cmd line
> > > C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> > > C:\cygwin64\home\maydin\test\main.exe
> > > C:\cygwin64\bin\cygwin1.dll
> > > C:\WINDOWS\system32\KERNEL32.dll
> > > C:\WINDOWS\system32\ntdll.dll
> > > C:\WINDOWS\system32\KERNELBASE.dll
> > >
> > > C:\cygwin64\home\maydin\test>ldd ./main.exe
> > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000)
> > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > > (0x7ffa90570000)
> > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > > (0x7ffa8ffb0000)
> > > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000)
> >
> > Looks OK.
> >
> > > //When cygwin terminal closed and cmd line command. Join throw fails.
> > > C:\cygwin64\home\maydin\test>main.exe
> > > Failed to join the thread t1.
> > > Failed to join the thread t2.
> > > r1 = 1, r2 = 1
> > >
> > > //when cygwin terminal opened. The test is passed.
> > > C:\cygwin64\home\maydin\test>main.exe
> > > r1 = 1, r2 = 1
> > >
> > >
> > > I think Cygwin terminal should be always open in order to execute a file in
> > > windows. Am I right ?
> >
> > It should not be. Weird enough.
> >
> > Could you please provide a strace log file such as:
> > strace -o faild.log ./main.exe
> > ?
>
> I looked into this problem, and I think this is a problem regarding
> _my_tls initialization order, so far. This seems to happen in LDAP
> environment.
>
> My assumption is:
>
> If the program is the first program which load cygwin1.dll, ldap
> connection seems to be made before pthread::init_mainthread().
> In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or
> cyg_ldap::next_page() calls cygwait() in which pthread::self()
> is called.
>
> Then, _my_tls.tid is initialized with null_pthread, therefore,
> _my_tls.tid is not set in pthread::init_mainthread().
>
> This causes pthread_join() failure at:
> winsup/cygwin/thread.cc: line 2196
> if (!is_good_object (&joiner))
> return EINVAL;
>
>
> The first idea to fix this issue is remove set_tls_self_pointer()
> call from pthread::self().
>
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 5c1284a93..a0f2d5546 100644
> --- a/winsup/cygwin/thread.cc
> +++ b/winsup/cygwin/thread.cc
> @@ -392,10 +392,7 @@ pthread::self ()
> {
> pthread *thread = _my_tls.tid;
> if (!thread)
> - {
> - thread = pthread_null::get_null_pthread ();
> - thread->set_tls_self_pointer ();
> - }
> + thread = pthread_null::get_null_pthread ();
> return thread;
> }
>
>
> The secnd approach is to re-initialize _my_tls.tid in
> pthread::init_mainthread() if _my_tls.tid is null_pthread.
>
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 5c1284a93..f614e01c4 100644
> --- a/winsup/cygwin/thread.cc
> +++ b/winsup/cygwin/thread.cc
> @@ -364,7 +364,7 @@ void
> pthread::init_mainthread ()
> {
> pthread *thread = _my_tls.tid;
> - if (!thread)
> + if (!thread || thread == pthread_null::get_null_pthread ())
> {
> thread = new pthread ();
> if (!thread)
>
>
> Which is the better approach, do you think?
> Or any other idea?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
2023-06-10 4:08 ` Takashi Yano
@ 2023-06-20 12:53 ` Takashi Yano
2023-06-22 10:19 ` Takashi Yano
0 siblings, 1 reply; 12+ messages in thread
From: Takashi Yano @ 2023-06-20 12:53 UTC (permalink / raw)
To: cygwin
On Sat, 10 Jun 2023 13:08:04 +0900 (JST)
Takashi Yano wrote:
> "M?min A." wrote:
> > //windows cmd line
> > C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> > C:\cygwin64\home\maydin\test\main.exe
> > C:\cygwin64\bin\cygwin1.dll
> > C:\WINDOWS\system32\KERNEL32.dll
> > C:\WINDOWS\system32\ntdll.dll
> > C:\WINDOWS\system32\KERNELBASE.dll
> >
> > C:\cygwin64\home\maydin\test>ldd ./main.exe
> > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000)
> > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffa90570000)
> > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffa8ffb0000)
> > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000)
>
> Looks OK.
>
> > //When cygwin terminal closed and cmd line command. Join throw fails.
> > C:\cygwin64\home\maydin\test>main.exe
> > Failed to join the thread t1.
> > Failed to join the thread t2.
> > r1 = 1, r2 = 1
> >
> > //when cygwin terminal opened. The test is passed.
> > C:\cygwin64\home\maydin\test>main.exe
> > r1 = 1, r2 = 1
> >
> >
> > I think Cygwin terminal should be always open in order to execute a file in
> > windows. Am I right ?
>
> It should not be. Weird enough.
>
> Could you please provide a strace log file such as:
> strace -o faild.log ./main.exe
> ?
I looked into this problem, and I think this is a problem regarding
_my_tls initialization order, so far. This seems to happen in LDAP
environment.
My assumption is:
If the program is the first program which load cygwin1.dll, ldap
connection seems to be made before pthread::init_mainthread().
In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or
cyg_ldap::next_page() calls cygwait() in which pthread::self()
is called.
Then, _my_tls.tid is initialized with null_pthread, therefore,
_my_tls.tid is not set in pthread::init_mainthread().
This causes pthread_join() failure at:
winsup/cygwin/thread.cc: line 2196
if (!is_good_object (&joiner))
return EINVAL;
The first idea to fix this issue is remove set_tls_self_pointer()
call from pthread::self().
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 5c1284a93..a0f2d5546 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -392,10 +392,7 @@ pthread::self ()
{
pthread *thread = _my_tls.tid;
if (!thread)
- {
- thread = pthread_null::get_null_pthread ();
- thread->set_tls_self_pointer ();
- }
+ thread = pthread_null::get_null_pthread ();
return thread;
}
The secnd approach is to re-initialize _my_tls.tid in
pthread::init_mainthread() if _my_tls.tid is null_pthread.
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 5c1284a93..f614e01c4 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -364,7 +364,7 @@ void
pthread::init_mainthread ()
{
pthread *thread = _my_tls.tid;
- if (!thread)
+ if (!thread || thread == pthread_null::get_null_pthread ())
{
thread = new pthread ();
if (!thread)
Which is the better approach, do you think?
Or any other idea?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
[not found] ` <64831a27.170a0220.1f805.81bfSMTPIN_ADDED_BROKEN@mx.google.com>
@ 2023-06-10 4:08 ` Takashi Yano
2023-06-20 12:53 ` Takashi Yano
0 siblings, 1 reply; 12+ messages in thread
From: Takashi Yano @ 2023-06-10 4:08 UTC (permalink / raw)
To: cygwin; +Cc: M?min A.
"M?min A." wrote:
> //windows cmd line
> C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> C:\cygwin64\home\maydin\test\main.exe
> C:\cygwin64\bin\cygwin1.dll
> C:\WINDOWS\system32\KERNEL32.dll
> C:\WINDOWS\system32\ntdll.dll
> C:\WINDOWS\system32\KERNELBASE.dll
>
> C:\cygwin64\home\maydin\test>ldd ./main.exe
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> (0x7ffa90570000)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> (0x7ffa8ffb0000)
> cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000)
Looks OK.
> //When cygwin terminal closed and cmd line command. Join throw fails.
> C:\cygwin64\home\maydin\test>main.exe
> Failed to join the thread t1.
> Failed to join the thread t2.
> r1 = 1, r2 = 1
>
> //when cygwin terminal opened. The test is passed.
> C:\cygwin64\home\maydin\test>main.exe
> r1 = 1, r2 = 1
>
>
> I think Cygwin terminal should be always open in order to execute a file in
> windows. Am I right ?
It should not be. Weird enough.
Could you please provide a strace log file such as:
strace -o faild.log ./main.exe
?
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Memory Barriers at pthread using CYGWIN
[not found] ` <96718c68-af84-45a5-9332-337ec4b2f04a@email.android.com>
@ 2023-06-09 12:25 ` Takashi Yano
0 siblings, 0 replies; 12+ messages in thread
From: Takashi Yano @ 2023-06-09 12:25 UTC (permalink / raw)
To: M?min A., cygwin
> I found a clue.
> I'm using cygwin as in windows environment path, C:\cygwin64\bin
>
> when I open the cygwin terminal , the test is passed but when I close
> cygwin terminal and run again the same test exe file then it fails.
>
> is there any connection about that ?
>
> The test is valid for native gcc compiler .t1, t2 have valid value.
Hmm...
Could you please check 'cygcheck ./a.exe' result?
Also 'ldd ./a.exe' might help.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-06-22 23:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-08 14:29 Memory Barriers at pthread using CYGWIN Mümin A.
2023-06-08 14:37 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-06-08 22:58 ` Mümin A.
2023-06-09 0:19 ` Kevin Schnitzius
2023-06-09 0:22 ` Takashi Yano
2023-06-09 1:44 ` Duncan Roe
[not found] <CAPxKPA6bRfF19pXrYT04TqbxettyYf=ypgfdySysqAJyB9BfxA@mail.gmail.com>
[not found] ` <CAPxKPA48sKPqwGc-jU7UQvQhsbT0N6A9LJXCAZeaa1rjeRtuNg@mail.gmail.com>
[not found] ` <96718c68-af84-45a5-9332-337ec4b2f04a@email.android.com>
2023-06-09 12:25 ` Takashi Yano
[not found] ` <64831a27.170a0220.1f805.81bfSMTPIN_ADDED_BROKEN@mx.google.com>
2023-06-10 4:08 ` Takashi Yano
2023-06-20 12:53 ` Takashi Yano
2023-06-22 10:19 ` Takashi Yano
2023-06-22 11:48 ` Corinna Vinschen
2023-06-22 23:49 ` Takashi Yano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).