RE: [EXTERNAL] Re: cygwin1.dll calls assert before cygwin command hangs
> 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 -- 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
Re: cygwin1.dll calls assert before cygwin command hangs
Sorry, the second gdb command should be info line *__assert+0x42a4 (Note the change in symbol name: two "_" there) ..mark -- 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
Re: cygwin1.dll calls assert before cygwin command hangs
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 -- 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
Re: newlocale: Linux incompatibility
On Mar 23 15:48, Ken Brown via Cygwin wrote:
> I'm reporting this here rather than the newlib list because the behavior is
> compatible with Posix but not Linux, so I think it's a Cygwin issue.
Actually, it's a Windows issue :)
> Consider the following test case:
>
> $ cat locale_test.c
> #include
> #include
>
> int main ()
> {
> const char *locale = "en_DE.UTF-8";
> locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
> if (!loc)
> perror ("newlocale");
> else
> printf ("newlocale succeeded on invalid locale %s\n", locale);
> }
>
> $ gcc -o locale_test locale_test.c
>
> $ ./locale_test.exe
> newlocale succeeded on invalid locale en_DE.UTF-8
>
> On Linux, the newlocale call fails with ENOENT, as is documented on the man
> page. Posix doesn't say what should happen on an invalid locale, so this is
> not, strictly speaking, a bug.
Three bugs in fact.
First, it's a bug in the Emacs testsuite. The test simply assumes that
there's no en_DE locale on any system, but that's just not true.
Windows support the RFC 5646 locale "en-DE", which is called "English
(Germany)" in the "Region" settings.
You can also check with `locale -av | less' and search for en_DE.
For the reminder of this mail, I assume you're talking about Cygwin 3.5.
I won't fix this for 3.4 anymore, given how much locale handling has
changed for 3.5.
The second bug is that Cygwin blindly trusts the Windows function
ResolveLocaleName(). That function blatantly converts even vaguely
similar locales into something it supports. E.g., it converts "en-XY"
to "en-US". I. .e., even if you use "en_XY.utf8" as locale, the above
testcase will wrongly succeed. So I have to rethink how I resolve POSIX
locales to Windows locales.
And the third bug is that Cygwin fails to set errno if it doesn't
support a locale, but that's a minor inconvenience in comparison.
Thanks for the report, I totally missed the above problem with
ResolveLocaleName.
Corinna
--
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
Re: newlocale: Linux incompatibility
Am 23.03.2023 um 20:48 schrieb Ken Brown via Cygwin:
I'm reporting this here rather than the newlib list because the
behavior is compatible with Posix but not Linux, so I think it's a
Cygwin issue.
Consider the following test case:
$ cat locale_test.c
#include
#include
int main ()
{
const char *locale = "en_DE.UTF-8";
locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
if (!loc)
perror ("newlocale");
else
printf ("newlocale succeeded on invalid locale %s\n", locale);
}
$ gcc -o locale_test locale_test.c
$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8
On Linux, the newlocale call fails with ENOENT, as is documented on
the man page. Posix doesn't say what should happen on an invalid
locale, so this is not, strictly speaking, a bug.
So the question is what is an invalid locale. In Linux, locales are only
valid if explicitly listed somewhere.
This strict behaviour may be a problem. A much better approach is to
allow any combination of known language_REGIOIN tags with encoding
indications, to be much more flexible and dynamic.
So if such combinations are considered legal, as in cygwin, this is not
a bug.
Ken
P.S. I noticed this because of a failing Emacs test. No one else has
reported this test failure, so it seems that newlocale fails on an
invalid locale on all platforms supported by Emacs other than Cygwin.
--
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
newlocale: Linux incompatibility
I'm reporting this here rather than the newlib list because the behavior
is compatible with Posix but not Linux, so I think it's a Cygwin issue.
Consider the following test case:
$ cat locale_test.c
#include
#include
int main ()
{
const char *locale = "en_DE.UTF-8";
locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
if (!loc)
perror ("newlocale");
else
printf ("newlocale succeeded on invalid locale %s\n", locale);
}
$ gcc -o locale_test locale_test.c
$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8
On Linux, the newlocale call fails with ENOENT, as is documented on the
man page. Posix doesn't say what should happen on an invalid locale, so
this is not, strictly speaking, a bug.
Ken
P.S. I noticed this because of a failing Emacs test. No one else has
reported this test failure, so it seems that newlocale fails on an
invalid locale on all platforms supported by Emacs other than Cygwin.
--
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
Re: [PATCH 0/3] fix unlink/rename failure in hyper-v container
On 2023/03/22 2:58, Corinna Vinschen wrote: > I pushed a new Cygwin DLL, test release 3.5.0-0.251.gfe2545e9faaf. > This should do what we want, now. If you can confirm, I'll push > your workaround afterwards. I have tested cygwin-3.5.0-0.251.gfe2545e9faaf. It works fine with bind mounted directory in the hyper-v container. However, the currently reported FILE_SUPPORTS_POSIX_UNLINK_RENAME and FILE_SUPPORTS_OPEN_BY_FILE_ID are different from the actual behavior and I will report this as a bug at https://github.com/microsoft/Windows-Containers/issues/341 In the future, I expect that FILE_SUPPORTS_POSIX_UNLINK_RENAME will be desirable as a check target, but then checking FILE_SUPPORTS_OPEN_BY_FILE_ID in gfe2545e9faafd may become harmful. (in process isolated container, posix unlink/rename works but OpenByFileId() not) At this time, using FILE_SUPPORTS_POSIX_UNLINK_RENAME for the check would mean the occurrence of additional failures and subsequent workarounds. This may be too optimistic, but STATUS_INVALID_PARAMETER is an error at the parameter check stage, so I expect a small loss in case of failure. Is the additional cost of unlink/rename failure due to an incorrect FILE_SUPPORTS_POSIX_UNLINK_RENAME unacceptable? Slightly off-topic, but since I could not use gui to set up cygwin in the container, I am using setup-x86_64.exe with cli. Is there a way to install the cygwin package by specifying the package version from cli? This time I modified setup.ini and installed with -l -L. -- Yoshinao Muramatsu
[PATCH cygport] git.cygclass: Try 'main' if there's no master branch
Patch attached.From 048a1e91cc9c4b14f4e17a6b52b6f4edb1843bf9 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Thu, 23 Mar 2023 09:20:14 -0400
Subject: [PATCH] git.cygclass: Try 'main' if there's no master branch
---
cygclass/git.cygclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index dd9aedbacdf2..e53a7985af99 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -93,7 +93,7 @@ git_fetch() {
#v* git.cygclass/GIT_BRANCH
# DESCRIPTION
-# Branch from which to clone. If undefined, the 'master' branch is used.
+# Branch from which to clone. If undefined, the 'master' or 'main' branch is
used.
#
#v* git.cygclass/GIT_REV
# DESCRIPTION
@@ -116,7 +116,7 @@ git_fetch() {
then
verbose git checkout ${GIT_REV} || error "git checkout failed"
else
- verbose git checkout master || error "git checkout failed"
+ verbose git checkout master || verbose git checkout main ||
error "git checkout failed"
fi
if [ -f .gitmodules ]
--
2.39.0
Re: Strange link /bin/rungs in 32-bit Cygwin
On 3/23/2023 9:10 AM, Fergus Daly via Cygwin wrote: Maybe of diminishing interest (32-bit Cygwin) - but: Out of nowhere (but see below (*)) a link has occurred /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua Can anybody confirm? The symlink and script come from texlive-collection-basic. In current TeX Live on 64-bit Cygwin, the link does indeed point to rungs.lua. But I think the .tlu extension is used for texlua scripts, so what you're seeing might not be a typo. I'd have to look back at last year's texlive-collection-basic to be sure, but you can do that more easily than I can, since you already have a system with last year's texlive-collection-basic. Ken -- 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
cygwin1.dll calls assert before cygwin command hangs
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 -- 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
Strange link /bin/rungs in 32-bit Cygwin
Maybe of diminishing interest (32-bit Cygwin) - but: Out of nowhere (but see below (*)) a link has occurred /bin/rungs -> /usr/share/texmf-dist/scripts/texlive/rungs.tlu which is, I think, a typo for /usr/share/texmf-dist/scripts/texlive/rungs.lua Can anybody confirm? (*) Weird. For no particular reason other than for OC fun I ran the 32-bit setup command setup-x86-2.924.exe --allow-unsupported-windows --site http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457 (all on one line) on an EXISTING setup (with, as anticipated, no obvious change to the entire resource and, in particular, no change to the timestamp 1669214097 i.e. almost exactly 17 weeks ago when Cygwin-32 was archived. Either (1) this error (if it is one) has been there all the time or (2) has been recently introduced. (1) would be odd because of the recently mentioned OCD and (2) would be odd because it raises questions How? and Why? Notwithstanding the diminishing relevance any enlightenment would be interesting and welcome. -- 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
RE: Parallel make hangs on 64-bit Cygwin
Hi Marco, >There was a discussion on the matter on the packager mailing list in February >https://cygwin.com/pipermail/cygwin-apps/2023-February/042624.html Thanks. I did search, but it seems Google's index doesn't include that thread: https://www.google.com/search?q=%22Heads+up%3A+Problems+with+parallel+make%22+site%3Ahttps%3A%2F%2Fcygwin.com%2F >Please try the test version of the package >https://cygwin.com/pipermail/cygwin-announce/2023-March/010972.html > >and let us know it the 4.4.1-2 version solves your problem Current version of make (4.4.1-1) with --jobserver-style=pipe works and the test build 4.4.1-2 works without needing that option. Thanks. Cheers, Jon -- 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
