public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mark Geisert <mark@maxrnd.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: cygwin1.dll calls assert before cygwin command hangs
Date: Thu, 23 Mar 2023 14:45:31 -0700	[thread overview]
Message-ID: <8a39b0f3-e79f-f50d-8810-4e0600d9aa9d@maxrnd.com> (raw)
In-Reply-To: <CH2PR02MB60247083CDBF095621D314CCE5879@CH2PR02MB6024.namprd02.prod.outlook.com>

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

  reply	other threads:[~2023-03-23 21:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 13:27 Derek Pagel
2023-03-23 21:45 ` Mark Geisert [this message]
2023-03-23 21:50   ` Mark Geisert
2023-03-24  3:32     ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a39b0f3-e79f-f50d-8810-4e0600d9aa9d@maxrnd.com \
    --to=mark@maxrnd.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).