cygwin1.dll calls assert before cygwin command hangs

[Mark Geisert]

Hi Derek,

Derek Pagel via Cygwin wrote:
> We've had problems with slow Cygwin commands, so we were able to capture a stack trace when the 'cp' program taking a long time to complete, and we noticed in the stack trace that the last thing cygwin1.dll does is calls assert. What might that suggest? And are there any situations that would cause an error on initialization?

This report is not specific enough to investigate at the moment.  Do all commands 
run slow?  If not, which commands run slowly?  Has the problem manifested recently 
or has it always been the case?  More below...

> Stack Trace:
> Child cmd.exe -> cp.exe -> cmd.exe -> cp.exe:

How exactly are you running Cygwin commands?  From a Command Prompt or a bash 
shell, for instance?  And how do you get the process tree you are indicating? 
What is the 'cp' command doing?  Paste the text of the command, please.

> ntoskrnl.exe!KeSynchronizeExecution+0x5a36
> ntoskrnl.exe!KeWaitForMutexObject+0x1c27
> ntoskrnl.exe!KeWaitForMutexObject+0x1799
> ntoskrnl.exe!KeWaitForMutexObject+0x520
> ntoskrnl.exe!IoQueueWorkItemEx+0x1a4
> ntoskrnl.exe!RtlInitializeSid+0x40d5
> ntoskrnl.exe!FsRtlRegisterFltMgrCalls+0x84225
> ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x269e
> ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2476
> ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2f05
> ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2af8
> ntoskrnl.exe!setjmpex+0x7925
> ntdll.dll!ZwQueryObject+0x14
> cygwin1.dll!dlfork+0xa0
> cygwin1.dll!dlfork+0x24d3
> cygwin1.dll!dlfork+0x2a9f
> cygwin1.dll!cygwin_dll_init+0x38f
> cygwin1.dll!_assert+0x41f6
> cygwin1.dll!_assert+0x42a4

Windows tools won't show full Cygwin debug info.  "_assert" in the above just 
happens to be the nearest global symbol below the actual address.  To get the 
actual address in a meaningful fashion, install the cygwin-debuginfo package, then run
     gdb -q /usr/lib/debug/usr/bin/cygwin1.dll.dbg
     info line __assert+0x42a4
(Note the change in symbol name: two "_" there)
This should work, but this is likely the wrong way to investigate the problem.

..mark