libfido2’s dependency on libcbor is dropped in setup.ini
cygfido2-1.dll (from libfido2-1.9.0-1) depends on cygcbor-0.8.dll . But the dependency is dropped in setup.ini (depends2 field). In addition, the current libcbor-0.9.0-2 doesn’t provide cygcbor-0.8.dll but cygcbor-0.9.dll . Maybe, libfido2 needs to be rebuilt with libcbor-0.9 . Thanks, — ggl329 -- 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
possible snprintf() regression in 3.3.2
This came up from regression testing perl.
Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c
used (from uname):
cygwin_nt-10.0 fv-az177-186 3.3.1(0.34153) 2021-10-28 20:52 x86_64 cygwin
this did not exhibit the problem. See
https://github.com/Perl/perl5/runs/4084168038?check_suite_focus=true
Testing of perl @a85e04e2281234a61c051f8f3ff63bed7381902c, the next
commit, which is purely a documentation change did exhibit the bug, used:
cygwin_nt-10.0 fv-az177-290 3.3.2(0.34153) 2021-11-08 16:55 x86_64 cygwin
which did crash. See
https://github.com/Perl/perl5/runs/4159124596?check_suite_focus=true
snprintf() appears to be crashing internally to ldtoa_r(), without
cygwin-debuginfo the backtrace is:
Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0 0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x7ffd26b21040 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x7ffd26b20e7b in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3 0x7ffd26b413a8 in ntdll!RtlRaiseException ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x7ffd26b90bfe in ntdll!KiUserExceptionDispatcher ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5 0x0001801fec7c in eiremain () from /usr/bin/cygwin1.dll
#6 0x000180200319 in _ldtoa_r () from /usr/bin/cygwin1.dll
#7 0x0001801cfca9 in _svfprintf_r () from /usr/bin/cygwin1.dll
#8 0x0001801bf327 in snprintf () from /usr/bin/cygwin1.dll
#9 0x00018018eb0b in _sigfe () from /usr/bin/cygwin1.dll
#10 0x52162647 in Perl_sv_vcatpvfn_flags (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501 "%.9f",
patlen=4, args=0xc550, svargs=0x0, sv_count=0, maybe_tainted=0x0,
flags=0) at sv.c:13482
#11 0x5215e360 in Perl_sv_vsetpvfn (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501 "%.9f",
patlen=4, args=0xc550, svargs=0x0, sv_count=0, maybe_tainted=0x0)
at sv.c:11271
#12 0x5215dde9 in Perl_sv_vsetpvf (my_perl=0x80004a3e0,
sv=0x800ca9e78, pat=0x523a3501 "%.9f",
args=0xc550) at sv.c:11101
#13 0x5215dd6a in Perl_sv_setpvf (my_perl=0x80004a3e0, sv=0x800ca9e78,
pat=0x523a3501 "%.9f") at sv.c:11076
#14 0x5210aa74 in Perl_upg_version (my_perl=0x80004a3e0,
ver=0x800cacb00, qv=false) at /home/tony/dev/perl/git/perl/vutil.c:700
#15 0x520440a4 in XS_universal_version (my_perl=0x80004a3e0,
cv=0x80004dfa0) at /home/tony/dev/perl/git/perl/vxs.inc:122
#16 0x52142b10 in Perl_pp_entersub (my_perl=0x80004a3e0)
at pp_hot.c:5361
#17 0x521318e7 in Perl_runops_standard (my_perl=0x80004a3e0)
at run.c:41
#18 0x520376ff in S_run_body (my_perl=0x80004a3e0, oldscope=1)
at perl.c:2715
#19 0x52037214 in perl_run (my_perl=0x80004a3e0) at perl.c:2643
#20 0x00010040117c in main (argc=4, argv=0xcc00, env=0x8000281a0)
at perlmain.c:110
With cygwin-debuginfo installed the backtrace is:
Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0 0x7ffd26b21548 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x7ffd26b21040 in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x7ffd26b20e7b in ntdll!RtlVirtualUnwind ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3 0x7ffd26b413a8 in ntdll!RtlRaiseException ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x7ffd26b90bfe in ntdll!KiUserExceptionDispatcher ()
from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5 0x0001801fec7c in eiremain (den=0x1, num=0x0, ldp=0x5)
at /usr/src/debug/cygwin-3.3.2-1/newlib/libc/stdlib/ldtoa.c:3736
#6 0x0001802bb0b0 in etens () from /usr/bin/cygwin1.dll
#7 0xbac2 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The stack appears to be badly corrupted (etens isn't a function).
Unfortunately I haven't been able to make a simple pure C reproducer
for this.
To reproduce:
Fetch and build perl (needs make, gcc):
$ git clone https://github.com/Perl/perl5.git
$ cd perl5
$ ./Configure -des -Dusedevel -Doptimize=-O0\ -g
# adjust -j6 to the desired parallel jobs
$ make -j6 test-prep
reproducing the original failure:
$ cd t ; gdb --args ./perl -I.. -MTestInit ../cpan/version/t/01base.t
a simpler test case, with some debugging:
$ echo '$Foo::VERSION = 9.e99; eval { Foo->VERSION(9e99) }' >mytest.pl
$ gdb --args ./perl mytest.pl
...
Reading symbols from ./perl...
(gdb) b vutil.c:700
No source file named vutil.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (vutil.c:700) pending.
(gdb) r
Starting prog
[ANNOUNCEMENT] Re-Release: libtool 2.4.6-8
The following packages have been uploaded to the Cygwin distribution: * libtool-2.4.6-8 * libltdl7-2.4.6-8 GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This release was rebuilt for GCC 11. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Editing with vim clears Windows 10 file system archive bit.
On Nov 15 14:18, Gary Johnson wrote: > On 2021-11-15, Corinna Vinschen via Cygwin wrote: > > Changing that is actually pretty simple, just set FILE_ATTRIBUTE_ARCHIVE > > as soon as the underlying NtCreateFile is called for an open(O_CREAT). > > > > Fixed in current git. > > I had thought that this might be a bug in Vim, so did a git bisect > to find the offending commit. For the record, it was this one: > [...] > The only change I see to an open() call was removing O_TRUNC on > systems with ftruncate() and adding a later call to ftruncate() on > systems that have it. There were also some changes to the setting > of permissions (fchown(), fchmod() and chmod()). These changes were > all in the buf_write() function in fileio.c. > > That open() call had the O_CREAT flag before and after the change. You are sooo right. My bugfix appears to work, but it's fixing a non-existent bug. NtCreateFile actually sets the ARCHIVE bit all the time when creating a new file, even if it's not explicitely given as parameter. That makes a lot of sense, of course, given how the archiving mechanism works on Windows. The *real* problem is in fact that Cygwin caches the wrong file attribute bits when creating a new file, and that's where fchmod fails: It writes back the wrongly cached bits. This doesn't happen with chmod, because it re-opens the existing file and fetches the correct attributes bit at the time. I guess I'll revert my patch and create a new one which is more to the point. Thanks, 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: Snapshot of Cygwin from Windows XP era
Follow up: there are now some of these historical cygwin releases and archives of the repos on archive.org. Last version to support Windows 9x/ME: https://archive.org/details/cygwin_repos_2009-12-01 Last version to support Windows 2000: https://archive.org/details/cygwin_repos_2013-06-04 Last version to support Windows XP: https://archive.org/details/cygwin_repos_2016-08-30 Snapshot from 2021-10-25: https://archive.org/details/cygwin_repos_2021-10-25 Hamish On 29/10/2021 00:37, Peter A. Castro wrote: On Thu, Oct 28, 2021 at 07:24:59PM +0100, Hamish McIntyre-Bhatty wrote: On 28/10/2021 17:14, Peter A. Castro wrote: On Thu, Oct 28, 2021 at 11:14:59AM +0100, Hamish McIntyre-Bhatty wrote: Greetings, Hamish, On 25/10/2021 17:37, Peter A. Castro wrote: On Sat, Oct 23, 2021 at 05:14:12PM +0100, Cygwin List wrote: Hi all, I was wondering if there exists a snapshot of the Cygwin repos at a time when Windows XP was still supported? Try the Cygwin Time Machine which has a continual collection of all Cygwin packages: http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html There you can find info specifically about the last XP release. Hope that helps, and good luck! Thanks, Hamish Cheers, found this later, but good to have a mention in the archive :) Could we link to the time machine from cygwin.org? It's not very easy to find as it is. Really? Google "Cygwin Time Machine" and it's the very first link. :) But, if you want to suggest something on the Cygwin list, be my guest. Well yes, but if you don't know that's what it's called... Ah... That is a valid point if one dives into Cygwin for the first time... Perhaps I could have choosen a more descriptive name? Maybe "Cygwin Archive"? But "Cygwin Archive" is a bit to broad and one could argue that the cygwin.com site is the (rightfully) current "archive" of Cygwin. Wouldn't want to detract from that. Well, people also search, more commonly, for "The last version of Cygwin to support XP" and that takes you to a Stackoverflow article which also talks about the Cygwin Time Machine. So, eventually, all roads lead to Rome...err, I mean the "Time Machine" :) Hamish OpenPGP_0x18F1759B3457223F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- 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: Cygwin 3.3.0 regression: "make" segmentation faults
On Mon, 15 Nov 2021 17:47:58 +0100 Aleksey Shipilev wrote: > OpenJDK project uses Cygwin to drive the OpenJDK build system under Windows. > Recently, our GitHub > Actions (GHA) Windows runs started to fail with make SEGV-ing: > https://bugs.openjdk.java.net/browse/JDK-8276854 > > This also reproduces locally for me, with the standard OpenJDK Windows build. > All sightings we had > are on Windows 10, but it is unclear if it is Windows 10 specific. > > The reproducer would be a bit hairy, because it requires MSVC 2019, JDK 17 > binary, and some other > dependencies to be installed for OpenJDK build. It goes like this: > > --- 8< --- --- --- --- --- --- --- --- > > > $ git clone https://github.com/openjdk/jdk/ jdk > $ cd jdk > $ sh ./configure --with-boot-jdk= --disable-warnings-as-errors > $ make clean jdk > ... > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 1 files for BUILD_TOOLS_HOTSPOT > Compiling 12 properties into resource bundles for jdk.jdeps > /usr/bin/bash: line 1: 1588 Segmentation fault (core dumped) > /usr/bin/make -s -r -R -I > /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common > SPEC=/cygdrive/d/a/jdk17u/jdk17u/jdk/build/windows-x64/spec.gmk > MAKE_LOG_FLAGS="-s" -f > ModuleWrapper.gmk -I /cygdrive/d/a/jdk17u/jdk17u/jdk/make/common/modules > -I/cygdrive/d/a/jdk17u/jdk17u/jdk/make/modules/java.base MODULE=java.base > MAKEFILE_PREFIX=Copy > make[2]: *** [make/Main.gmk:157: java.base-copy] Error 139 > make[2]: *** Waiting for unfinished jobs > Compiling 7 properties into resource bundles for jdk.jshell > > --- 8< --- --- --- --- --- --- --- --- Thanks for the report. I could reproduce the problem and found that the cause is the same with: https://cygwin.com/pipermail/cygwin/2021-November/249913.html I will submit the patch for these issues shortly. -- Takashi Yano -- 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
