cygwin1.dll calls assert before cygwin command hangs

cygwin1.dll calls assert before cygwin command hangs

[Derek Pagel]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

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?

Stack Trace:
Child cmd.exe -> cp.exe -> cmd.exe -> cp.exe:
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

Re: 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

Re: cygwin1.dll calls assert before cygwin command hangs

[Mark Geisert]

Sorry, the second gdb command should be
     info line *__assert+0x42a4
> (Note the change in symbol name: two "_" there)

..mark

RE: [EXTERNAL] Re: cygwin1.dll calls assert before cygwin command hangs

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> Sorry, the second gdb command should be
>      info line *__assert+0x42a4
> > (Note the change in symbol name: two "_" there)
>

I think it'd be easier to "catch" the problem rather than to chase it by running all commands under the debugger.

For that, define the CYGWIN environment variable (via Windows) as:
error_start=c:\cygwin64\bin\dumper.exe

(that assumes that Cygwin is installed at c:\cygwin64)

Then whenever the abort occurs, you'll have a core file, which can be loaded into GDB and the backtrace investigated.
Something like this:

$ gdb /path/to/command command.core
(gdb) where

My $.02,

Anton Lavrentiev
Contractor NIH/NLM/NCBI