DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DB97B3894E6B
Date: Wed, 6 May 2020 06:10:33 +0000 (UTC)
To: cygwin AT cygwin DOT com
Message-ID: <849984783.2025130.1588745433116@mail.yahoo.com>
In-Reply-To: <1599677377.20200504184247@yandex.ru>
References: <475030844 DOT 772124 DOT 1588585159800 DOT ref AT mail DOT yahoo DOT com>
 <475030844 DOT 772124 DOT 1588585159800 AT mail DOT yahoo DOT com>
 <1599677377 DOT 20200504184247 AT yandex DOT ru>
Subject: Re: CygWin / Sshd / ssh-keygen hangs
MIME-Version: 1.0
Precedence: list
From: Cezar Damian via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Cezar Damian <cezar DOT damian AT yahoo DOT com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

 
Hi Andrew,
I'm not using W10 components, I have only cygwin installed with open-ssh and rsync.Unfortunatelly disable_pcon didn't help, I have the same issue :
- ssh-keygen hangs- sshd - hangs with high CPU usage ( 100% split on number of instances )- I don't see any handles or files open by sshd or ssh-keygen- when debuggin with windbg I got cygwin1.dll waiting for a get_perm_acl, but only once
BTW, I'm runnig sshd as service, but also in console, via bash, is hanging.
Could it be that the fact that W10 is in a VMWare has some impact on cygWin ?
Regards,
Cezar Damian
    On Monday, May 4, 2020, 05:50:05 PM GMT+2, Andrey Repin <anrdaemon AT yandex DOT ru> wrote:  
 
 Greetings, Cezar Damian!


> When trying to run ssh-keygen or sshd from Cygwin bash both of them are
> hanging.

> Wehave the following configuration :
>    
>    - CygWin – latest version
>    - Openssh – latest available version
>    - OS – W10 running in a VMWare environment

> When attaching with gdb to the process, I can see that ssh-keygen threads
> are waiting for something ( see below ) and the program is blocked in
> pthread_setspecific ().

>  

> Do you have any idea what is causing such a behaviorand how can we:
>    
>    - Work around it
>    - Understand what causes it ?

This can be an external (to Cygwin) issue, and I see tha tyou are indeed using
Cygwin's ssh-keyegen for all that I can tell, but please double-check that you
aren't actually using Win10 peovided OpenSSH components.

To the hangs, try running them with CYGWIN=disable_pcon for a test.

> Thank you,

> Cezar Damian

> (gdb) info threads

>   Id   TargetId           Frame

>   1    Thread 14616.0x2ccc0x00007ffa62e30154 in ntdll!ZwWaitForSingleObject
> () from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   2    Thread 14616.0x3d0c0x00007ffa62e339e4 in
> ntdll!ZwWaitForWorkViaWorkerFactory ()
> from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   3    Thread 14616.0x12c40x00007ffa62e339e4 in
> ntdll!ZwWaitForWorkViaWorkerFactory ()
> from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   4    Thread 14616.0x32ac0x00007ffa62e339e4 in
> ntdll!ZwWaitForWorkViaWorkerFactory ()
> from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

> * 5    Thread 14616.0x33040x0000000000000000 in ?? ()

>   6    Thread 14616.0x38a80x00007ffa62e30194 in ntdll!ZwReadFile () from
> /cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   7    Thread 14616.0x8f0 0x00007ffa62e30c24 in
> ntdll!ZwWaitForMultipleObjects () from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   8    Thread 14616.0x3d540x00007ffa62e30c24 in
> ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll

>   9    Thread 14616.0x1ab40x00007ffa62dbec08 in ntdll!LdrShutdownThread ()
> from/cygdrive/c/Windows/SYSTEM32/ntdll.dll

>  

> (gdb) backtrace full

> #0  0x0000000000000000 in ?? ()

> No symbol table info available.

> #1  0x0000000180163eb0 in pthread_setspecific ()at
> /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/thread.cc:2858

>        pthread_key::keys = {mx = {lock_counter = 0, win32_obj_id = 0xcc}, head =0x800064fb0}

>         pthread_rwlock::rwlocks= {mx = {lock_counter = 0, win32_obj_id = 0xc8}, head = 0x8000659a0}

>        pthread::threads = {mx = {lock_counter = 0, win32_obj_id = 0xbc}, head =0x800000010}

>        pthread_mutex::mutex_initialization_lock = {lock_counter = 0, win32_obj_id =0x254}

>        pthread_null::_instance = {<pthread> = {<verifyable_object> = {

>              _vptr.verifyable_object = 0x1802bdea0 <vtable for
> pthread_null+16>, magic= 0}, win32_obj_id = 0x0,

>            attr = {<verifyable_object> = {_vptr.verifyable_object
> =0x1802bde60 <vtable for pthread_attr+16>, magic = 3742232648},

>              joinable = 1, contentionscope = 0, inheritsched = 0,
> schedparam ={sched_priority = 0}, stackaddr = 0x0, stacksize = 0,

>              guardsize= 12288, name = 0x0}, function = 0x0, arg = 0x0,
> return_ptr = 0x0, valid =false, suspended = false,

>            canceled = false, cancelstate = 0, canceltype = 0, cygtls = 0x0,
> cancel_event =0x0, joiner = 0x0, next = 0x0,

>            static threads = {mx = {lock_counter = 0, win32_obj_id =0xbc},
> head = 0x800000010}, thread_id = 0, cleanup_stack = 0x0,

>            mutex = {<verifyable_object> = {_vptr.verifyable_object =
> 0x1802bed20<vtable for pthread_mutex+16>, magic = 3742232646},

>              next = 0x0, lock_counter = 0, win32_obj_id = 0xd8, owner =
> 0x1, static_new_mutex = 0x1, static _unlocked_mutex = 0x2,

>              static _destroyed_mutex = 0x3, recursion_counter = 0,
> condwaits = 0, type = 2,pshared = 0, static mutexes = {mx = {

>                  lock_counter = 0, win32_obj_id = 0xd0}, head =
> 0x800065b38}, staticmutex_initialization_lock = {lock_counter = 0,

>                win32_obj_id = 0x254}}, parent_sigmask = 0}, static
> _instance ={<pthread> = {<verifyable_object> = {

>                _vptr.verifyable_object = 0x1802bdea0 <vtable for
> pthread_null+16>, magic= 0}, win32_obj_id = 0x0,

>              attr = {<verifyable_object> = {_vptr.verifyable_object =
> 0x1802bde60<vtable for pthread_attr+16>, magic = 3742232648},

>                joinable= 1, contentionscope = 0, inheritsched = 0,
> schedparam = {sched_priority = 0},stackaddr = 0x0,

>                stacksize = 0, guardsize = 12288, name = 0x0}, function =
> 0x0, arg = 0x0,return_ptr = 0x0, valid = false,

>              suspended = false, canceled = false, cancelstate = 0,
> canceltype = 0, cygtls =0x0, cancel_event = 0x0, joiner = 0x0,

>              next = 0x0, static threads = {mx = {lock_counter = 0,
> win32_obj_id = 0xbc},head = 0x800000010}, thread_id = 0,

>              cleanup_stack = 0x0, mutex = {<verifyable_object> = {

>                  _vptr.verifyable_object = 0x1802bed20 <vtable for
> pthread_mutex+16>,magic = 3742232646}, next = 0x0,

>                lock_counter = 0, win32_obj_id = 0xd8, owner = 0x1, static
> _new_mutex = 0x1,static _unlocked_mutex = 0x2,

>                static _destroyed_mutex = 0x3, recursion_counter = 0,
> condwaits = 0, type = 2,pshared = 0, static mutexes = {mx = {

>                    lock_counter = 0, win32_obj_id = 0xd0}, head =
> 0x800065b38}, staticmutex_initialization_lock = {

>                  lock_counter = 0, win32_obj_id = 0x254}}, parent_sigmask = 0},

>            static _instance = <same as static member of an already seen type>}}

>        pthread_rwlock::rwlock_initialization_lock = {lock_counter = 0, win32_obj_id =0x108}

>        semaphore::semaphores = {mx = {lock_counter = 0, win32_obj_id = 0xd4}, head =0x0}

>        pthread_cond::conds = {mx = {lock_counter = 0, win32_obj_id = 0xc4}, head =0x800065ad0}

>        pthread_cond::cond_initialization_lock = {lock_counter = 0, win32_obj_id =0x104}

> --Type <RET> for more, q to quit, c to continuewithout paging--

>        pthread_mutex::mutexes = {mx = {lock_counter = 0, win32_obj_id = 0xd0}, head =0x800065b38}

> Backtrace stopped: Cannot access memory at address 0x0

> (gdb)


-- 
With best regards,
Andrey Repin
Monday, May 4, 2020 18:39:42

Sorry for my terrible english...  
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple