Re: Unable to push to cygutils git repo on sourceware
Hi Mark, On 2021-09-06 21:46, Mark Geisert wrote: Something's likely changed in the 4 years since I last did this :-). Your memory's faded! ;^> It's taken me months of use to remember correctly! For most Cygwin packages it's: https://cygwin.com/git-cygwin-packages/ https://cygwin.com/git/cygwin-packages/PKG.git # no longer works! https://cygwin.com/git/?p=git/cygwin-packages/PKG.git ssh://cyg...@cygwin.com/git/cygwin-packages/PKG.git but yours is a Cygwin *app*: https://cygwin.com/git/cygwin-apps/ https://cygwin.com/git/cygwin-apps/cygutils.git https://cygwin.com/git?p=cygwin-apps/cygutils.git ssh://cyg...@cygwin.com/git/cygwin-apps/cygutils.git $ git push fatal: remote error: service not enabled: /git/cygwin-cygutils.git $ cat .git/config [core] # blah elided [remote "origin"] url = git://sourceware.org/git/cygwin-cygutils.git url = ssh://cyg...@cygwin.com/git/cygwin-apps/cygutils [You may also use any .ssh/config Host alias for cyg...@cygwin.com which references your SSH key for Cygwin access] fetch = +refs/heads/*:refs/remotes/origin/* > [branch "master"] remote = origin merge = refs/heads/master [branch "playground"] remote = origin merge = refs/heads/playground I tried cygwin.com in place of sourceware.org but no change. Have the repositories moved or the access policies changed? Thanks for any leads, -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: Broken dependencies for net-snmp-utils and perl-net-snmp
On 2021-06-24 02:14, Dan Andersson via Cygwin wrote: I'm having trouble installing net-snmp-utils-5.8-1. When using Cygwin Setup and I attempt to install net-snmp-utils-5.8-1, I receive the following error when resolving dependencies: Problem 1/1 nothing provides perl5_026 needed by perl-net-snmp-5.7.2-2 Solution 1/1 (default) - do not ask to install net-snmp-utils-5.8-1 If I attempt to install various versions of perl-net-snmp: Problem 1/1 nothing provides perl5_026 needed by perl-net-snmp-5.7.2-2 Solution 1/1 (default) - do not ask to install perl-net-snmp-5.7.2-2 Problem 1/1 nothing provides perl5_026 needed by perl-net-snmp-5.7.3-1 Solution 1/1 (default) - do not ask to install perl-net-snmp-5.7.3-1 Problem 1/1 package perl-net-snmp-5.8-1 requires perl5_030, but none of the providers can be installed Solution 1/1 (default) - do not ask to install perl-net-snmp-5.8-1 So the root cause appears to be a problem finding perl5_030 or perl5_026. Any suggestions? Should be satisfied by Cygwin Setup with recent perl_base but you may have to pick explicit version 5.30.3-1 or perl-net-snmp needs updated to current: $ awk -v'RS=\n@ ' -F'\n' '/provides: perl5_0/' ~/mirror/x86_64/setup.ini perl_base sdesc: "Perl programming language interpreter" ldesc: "Perl programming language interpreter Minimal install intended for use by Base packages." category: Interpreters Perl requires: cygwin libcrypt2 perl_autorebase version: 5.32.1-2 install: x86_64/release/perl/perl_base/perl_base-5.32.1-2.tar.zst 3535254 21cfd8a48cccbb17ab4bca82544ba201e4c71c27079a7db991c11ed32763ec1b061fca5596c82130cb403187cb344a32fc1c2790b69bd5c0a416833984e8e091 source: x86_64/release/perl/perl-5.32.1-2-src.tar.zst 12620342 183471f03264bce46519792025adf0b522ba9b30d8acdaccdb62971068b2d40f51d435431d243382b29b8ed1e38b811248964fc054813e901168b25e078b81a2 depends2: cygwin, libcrypt2, perl_autorebase obsoletes: perl-CPAN-Meta, perl-CPAN-Meta-Requirements, perl-Carp, perl-Config-Perl-V, perl-Crypt-OpenSSL-ECDSA, perl-Data-Alias, perl-Gnome2, perl-Gnome2-Canvas, perl-Gnome2-GConf, perl-Gnome2-Rsvg, perl-Gnome2-VFS, perl-Gnome2-Vte, perl-Gnome2-Wnck, perl-Gtk2, perl-Gtk2-GladeXML, perl-Gtk2-Notify, perl-Gtk2-SourceView2, perl-Gtk2-Spell, perl-Gtk2-Unique, perl-Gtk2-WebKit, perl-Module-Load-Conditional, perl-Pod-Simple, perl-Win32, perl-XSLoader build-depends: cygport provides: perl5_032 [prev] version: 5.30.3-1 install: x86_64/release/perl/perl_base/perl_base-5.30.3-1.tar.xz 3199864 d9e9747aff88707b34b74b7f8fb4f409b8b3117a6dacca8e1a0110268e08a4cd942c59d2a170759f431a4bf372872ff340b79281626fcd8058b954299a7a0552 source: x86_64/release/perl/perl-5.30.3-1-src.tar.xz 12391460 5071e64e1338050cf790c219b2165f092e5f991fbdc31671ab6d2bdb30c20b528e279a304587ca1d57016e58cd6f6a1799616517ae7dc57ce6031bb9ea393f5d depends2: cygwin, libcrypt2 build-depends: cygport provides: perl5_030 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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
Unable to push to cygutils git repo on sourceware
Something's likely changed in the 4 years since I last did this :-). $ git push fatal: remote error: service not enabled: /git/cygwin-cygutils.git $ cat .git/config [core] # blah elided [remote "origin"] url = git://sourceware.org/git/cygwin-cygutils.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master I tried cygwin.com in place of sourceware.org but no change. Have the repositories moved or the access policies changed? Thanks for any leads, ..mark
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 2021-09-06 15:24, Ken Brown via Cygwin wrote:
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the DLL. That
doesn't
make sense for sure. However, I ran the testcase under GDB, I could
reproduce the issue, and I could fix it by setting mmap_ext.Reserved
= 0;
Go figure!
I don't get it, but I can confirm that the problem is fixed.
That sounds a bit like a voodoo fix, that could quickly regress again.
Here is my 2 cents:
Currently the mmap_ext structure is setup like this:
215 MEM_EXTENDED_PARAMETER mmap_ext = {
216 .Type = MemExtendedParameterAddressRequirements,
217 .Pointer = (PVOID) _req
218 };
This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization
So if you set "mmap_ext.Reserved = 0" again after that its a double
failure.
You're looking at the wrong source code. The bug didn't occur until the
code was changed to do the following:
/* g++ 11.2 workaround: don't use initializer */
MEM_EXTENDED_PARAMETER mmap_ext;
mmap_ext.Type = MemExtendedParameterAddressRequirements;
mmap_ext.Pointer = (PVOID) _req;
This left mmap_ext.Reserved uninitialized, which Corinna has now fixed.
With undocumented structure member initialization an issue, maybe better
to future proof using e.g.
MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero
...
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 5:24 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the DLL. That
doesn't
make sense for sure. However, I ran the testcase under GDB, I could
reproduce the issue, and I could fix it by setting mmap_ext.Reserved
= 0;
Go figure!
I don't get it, but I can confirm that the problem is fixed.
That sounds a bit like a voodoo fix, that could quickly regress again.
Here is my 2 cents:
Currently the mmap_ext structure is setup like this:
215 MEM_EXTENDED_PARAMETER mmap_ext = {
216 .Type = MemExtendedParameterAddressRequirements,
217 .Pointer = (PVOID) _req
218 };
This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization
So if you set "mmap_ext.Reserved = 0" again after that its a double
failure.
You're looking at the wrong source code. The bug didn't occur until the code
was changed to do the following:
/* g++ 11.2 workaround: don't use initializer */
MEM_EXTENDED_PARAMETER mmap_ext;
mmap_ext.Type = MemExtendedParameterAddressRequirements;
mmap_ext.Pointer = (PVOID) _req;
This left mmap_ext.Reserved uninitialized, which Corinna has now fixed.
I should add that when I said "I don't get it", I wasn't referring to Corinna's
fix. I was referring to the fact that the bug did *not* occur when the
unoptimized build was run under gdb.
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
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the DLL. That
doesn't
make sense for sure. However, I ran the testcase under GDB, I could
reproduce the issue, and I could fix it by setting mmap_ext.Reserved
= 0;
Go figure!
I don't get it, but I can confirm that the problem is fixed.
That sounds a bit like a voodoo fix, that could quickly regress again.
Here is my 2 cents:
Currently the mmap_ext structure is setup like this:
215 MEM_EXTENDED_PARAMETER mmap_ext = {
216 .Type = MemExtendedParameterAddressRequirements,
217 .Pointer = (PVOID) _req
218 };
This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization
So if you set "mmap_ext.Reserved = 0" again after that its a double
failure.
You're looking at the wrong source code. The bug didn't occur until the code
was changed to do the following:
/* g++ 11.2 workaround: don't use initializer */
MEM_EXTENDED_PARAMETER mmap_ext;
mmap_ext.Type = MemExtendedParameterAddressRequirements;
mmap_ext.Pointer = (PVOID) _req;
This left mmap_ext.Reserved uninitialized, which Corinna has now fixed.
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
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I could
> > reproduce the issue, and I could fix it by setting mmap_ext.Reserved
> > = 0;
> > Go figure!
>
> I don't get it, but I can confirm that the problem is fixed.
That sounds a bit like a voodoo fix, that could quickly regress again.
Here is my 2 cents:
Currently the mmap_ext structure is setup like this:
215 MEM_EXTENDED_PARAMETER mmap_ext = {
216 .Type = MemExtendedParameterAddressRequirements,
217 .Pointer = (PVOID) _req
218 };
This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization
So if you set "mmap_ext.Reserved = 0" again after that its a double
failure.
1) The compiler should ignore it as it is redundent.
2) It makes no sense, as it is already zero :-)
Since it is not ignored, the compiler clearly puts in code to to
reinitialize the variable (which some compilers do not optimize for).
The reason this makes it "work" it probably because of some other stack
curruption that is going on which then disappears because of the code
moving around a bit due to the new line. My best guess would be that
other fun stuff in the same location would also "fix" the problem.
These are not the droids you are looking for. The real problem is
elsewhere, and is likely due to some stack-smashing going on. This is
also likely why recompiling the test program makes a difference as that
changes what goes on the variable stack. When the code moves around
again (e.g. new compiler version), it could break again.
Looking at the test program -02 vs -O0:
pushq %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe %rbp, 0
subq$64, %rsp
.seh_stackalloc 64
.seh_endprologue
vs
subq$56, %rsp
.seh_stackalloc 56
Which gives a different stack layout. I think the problem must be in
the start of mmap() or subsequent calls like CreateMapping() and
MapView(). Something smashes or affects the stack.
Thanks,
/pedro
--
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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I could
> > reproduce the issue, and I could fix it by setting mmap_ext.Reserved
> > = 0;
> > Go figure!
>
> I don't get it, but I can confirm that the problem is fixed.
That sounds a bit like a voodoo fix, that could quickly regress again.
Here is my 2 cents:
Currently the mmap_ext structure is setup like this:
215 MEM_EXTENDED_PARAMETER mmap_ext = {
216 .Type = MemExtendedParameterAddressRequirements,
217 .Pointer = (PVOID) _req
218 };
This means that all other entries in the struct are zero at
initialization as described here:
https://en.cppreference.com/w/c/language/struct_initialization
So if you set "mmap_ext.Reserved = 0" again after that its a double
failure.
1) The compiler should ignore it as it is redundent.
2) It makes no sense, as it is already zero :-)
Since it is not ignored, the compiler clearly puts in code to to
reinitialize the variable (which some compilers do not optimize for).
The reason this makes it "work" it probably because of some other stack
curruption that is going on which then disappears because of the code
moving around a bit due to the new line. My best guess would be that
other fun stuff in the same location would also "fix" the problem.
These are not the droids you are looking for. The real problem is
elsewhere, and is likely due to some stack-smashing going on. This is
also likely why recompiling the test program makes a difference as that
changes what goes on the variable stack. When the code moves around
again (e.g. new compiler version), it could break again.
Looking at the test program -02 vs -O0:
pushq %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe %rbp, 0
subq$64, %rsp
.seh_stackalloc 64
.seh_endprologue
vs
subq$56, %rsp
.seh_stackalloc 56
Which gives a different stack layout. I think the problem must be in
the start of mmap() or subsequent calls like CreateMapping() and
MapView(). Something smashes or affects the stack.
Thanks,
/pedro
--
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
Broken dependencies for net-snmp-utils and perl-net-snmp
Did you ever find fix for this? Rick Gumpertz -- 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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 2:07 PM, Corinna Vinschen via Cygwin wrote: On Sep 6 19:59, Corinna Vinschen via Cygwin wrote: On Sep 6 13:38, Ken Brown via Cygwin wrote: On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: On Sep 5 09:24, Ken Brown via Cygwin wrote: On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: Here are the correct commits: 8169e39ab Cygwin: C++17: register keyword is deprecated 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 bdb7991db Cygwin: workaround a g++ 11.2 initialization bug 801120c1f Cygwin: loader script: add DWARF 5 sections d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning c2fe205b5 strstr: avoid warnings 76c2c7a89 ldexp/ldexpf: avoid assembler warning eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString So there appears to be something wrong with cygwin1.dll built with the current build tools (gcc 11.2.0, binutils 2.37, not sure what else is relevant). Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER initialization problem that was dealt with in commit bdb7991db. More data: When I run the test case under gdb, it succeeds. When I run it under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with windows error 87. Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, perhaps? I tried removing them, and I got the same error. I also tried removing static, and I tried removing both static and const. BTW, when I reported that the test case succeeds under gdb, that only happens when I build the test case without optimization. If I build with -O2, it fails under gdb also. [In all my tests, I built cygwin1.dll without optimization.] This makes no sense to me at all. Good hint. I found the culprit. With optimization, the code doesn't set the "Reserved" bits in the first struct of MEM_EXTENDED_PARAMETER to 0. No, wait. I get what you say. The optimzation settings of the test case should have no influence on the code inside the DLL. That doesn't make sense for sure. However, I ran the testcase under GDB, I could reproduce the issue, and I could fix it by setting mmap_ext.Reserved = 0; Go figure! I don't get it, but I can confirm that the problem is fixed. Thanks. 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
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On Sep 6 19:59, Corinna Vinschen via Cygwin wrote: > On Sep 6 13:38, Ken Brown via Cygwin wrote: > > On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: > > > On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: > > > > On Sep 5 09:24, Ken Brown via Cygwin wrote: > > > > > On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: > > > > > > On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: > > > > > > > Here are the correct commits: > > > > > > > > > > > > > > 8169e39ab Cygwin: C++17: register keyword is deprecated > > > > > > > 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 > > > > > > > bdb7991db Cygwin: workaround a g++ 11.2 initialization bug > > > > > > > 801120c1f Cygwin: loader script: add DWARF 5 sections > > > > > > > d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning > > > > > > > c2fe205b5 strstr: avoid warnings > > > > > > > 76c2c7a89 ldexp/ldexpf: avoid assembler warning > > > > > > > eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString > > > > > > > > > > > > > > > > > > > > > > > > So there appears to be something wrong with cygwin1.dll > > > > > > > > > built with the current build tools (gcc 11.2.0, binutils > > > > > > > > > 2.37, not sure what else is relevant). > > > > > > > > > > > > Wait a minute...I'll bet this is related to the > > > > > > MEM_EXTENDED_PARAMETER > > > > > > initialization problem that was dealt with in commit bdb7991db. > > > > > > > > > > More data: When I run the test case under gdb, it succeeds. When I > > > > > run it > > > > > under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing > > > > > with > > > > > windows error 87. > > > > > > > > Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, > > > > perhaps? > > > > > > I tried removing them, and I got the same error. I also tried removing > > > static, and I tried removing both static and const. > > > > BTW, when I reported that the test case succeeds under gdb, that only > > happens when I build the test case without optimization. If I build with > > -O2, it fails under gdb also. [In all my tests, I built cygwin1.dll without > > optimization.] This makes no sense to me at all. > > Good hint. I found the culprit. With optimization, the code doesn't > set the "Reserved" bits in the first struct of MEM_EXTENDED_PARAMETER > to 0. No, wait. I get what you say. The optimzation settings of the test case should have no influence on the code inside the DLL. That doesn't make sense for sure. However, I ran the testcase under GDB, I could reproduce the issue, and I could fix it by setting mmap_ext.Reserved = 0; Go figure! 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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On Sep 6 13:38, Ken Brown via Cygwin wrote: > On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: > > On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: > > > On Sep 5 09:24, Ken Brown via Cygwin wrote: > > > > On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: > > > > > On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: > > > > > > Here are the correct commits: > > > > > > > > > > > > 8169e39ab Cygwin: C++17: register keyword is deprecated > > > > > > 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 > > > > > > bdb7991db Cygwin: workaround a g++ 11.2 initialization bug > > > > > > 801120c1f Cygwin: loader script: add DWARF 5 sections > > > > > > d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning > > > > > > c2fe205b5 strstr: avoid warnings > > > > > > 76c2c7a89 ldexp/ldexpf: avoid assembler warning > > > > > > eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString > > > > > > > > > > > > > > > > > > > > > So there appears to be something wrong with cygwin1.dll > > > > > > > > built with the current build tools (gcc 11.2.0, binutils > > > > > > > > 2.37, not sure what else is relevant). > > > > > > > > > > Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER > > > > > initialization problem that was dealt with in commit bdb7991db. > > > > > > > > More data: When I run the test case under gdb, it succeeds. When I run > > > > it > > > > under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing > > > > with > > > > windows error 87. > > > > > > Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, > > > perhaps? > > > > I tried removing them, and I got the same error. I also tried removing > > static, and I tried removing both static and const. > > BTW, when I reported that the test case succeeds under gdb, that only > happens when I build the test case without optimization. If I build with > -O2, it fails under gdb also. [In all my tests, I built cygwin1.dll without > optimization.] This makes no sense to me at all. Good hint. I found the culprit. With optimization, the code doesn't set the "Reserved" bits in the first struct of MEM_EXTENDED_PARAMETER to 0. This is at least required by the VirtualAlloc2 function, though. Needless to say that this behaviour isn't documented... I'll push a patch shortly. 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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 1:38 PM, Ken Brown via Cygwin wrote: On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: On Sep 5 09:24, Ken Brown via Cygwin wrote: On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: Here are the correct commits: 8169e39ab Cygwin: C++17: register keyword is deprecated 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 bdb7991db Cygwin: workaround a g++ 11.2 initialization bug 801120c1f Cygwin: loader script: add DWARF 5 sections d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning c2fe205b5 strstr: avoid warnings 76c2c7a89 ldexp/ldexpf: avoid assembler warning eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString So there appears to be something wrong with cygwin1.dll built with the current build tools (gcc 11.2.0, binutils 2.37, not sure what else is relevant). Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER initialization problem that was dealt with in commit bdb7991db. More data: When I run the test case under gdb, it succeeds. When I run it under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with windows error 87. Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, perhaps? I tried removing them, and I got the same error. I also tried removing static, and I tried removing both static and const. BTW, when I reported that the test case succeeds under gdb, that only happens when I build the test case without optimization. If I build with -O2, it fails under gdb also. [In all my tests, I built cygwin1.dll without optimization.] This makes no sense to me at all. There can be a number of possibilities, but I wonder about a variable uninitialized along some path. By accident, the contents may have a non-failing value with -O0 by the situation can be different for -O2. If you're dealing with concurrency and such, then -O0 and -O2 can act differently with respect to races. Just some thoughts ... Best - Eliot Moss -- 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: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote: On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: On Sep 5 09:24, Ken Brown via Cygwin wrote: On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: Here are the correct commits: 8169e39ab Cygwin: C++17: register keyword is deprecated 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 bdb7991db Cygwin: workaround a g++ 11.2 initialization bug 801120c1f Cygwin: loader script: add DWARF 5 sections d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning c2fe205b5 strstr: avoid warnings 76c2c7a89 ldexp/ldexpf: avoid assembler warning eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString So there appears to be something wrong with cygwin1.dll built with the current build tools (gcc 11.2.0, binutils 2.37, not sure what else is relevant). Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER initialization problem that was dealt with in commit bdb7991db. More data: When I run the test case under gdb, it succeeds. When I run it under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with windows error 87. Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, perhaps? I tried removing them, and I got the same error. I also tried removing static, and I tried removing both static and const. BTW, when I reported that the test case succeeds under gdb, that only happens when I build the test case without optimization. If I build with -O2, it fails under gdb also. [In all my tests, I built cygwin1.dll without optimization.] This makes no sense to me at all. 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
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote: On Sep 5 09:24, Ken Brown via Cygwin wrote: On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: Here are the correct commits: 8169e39ab Cygwin: C++17: register keyword is deprecated 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 bdb7991db Cygwin: workaround a g++ 11.2 initialization bug 801120c1f Cygwin: loader script: add DWARF 5 sections d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning c2fe205b5 strstr: avoid warnings 76c2c7a89 ldexp/ldexpf: avoid assembler warning eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString So there appears to be something wrong with cygwin1.dll built with the current build tools (gcc 11.2.0, binutils 2.37, not sure what else is relevant). Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER initialization problem that was dealt with in commit bdb7991db. More data: When I run the test case under gdb, it succeeds. When I run it under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with windows error 87. Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, perhaps? I tried removing them, and I got the same error. I also tried removing static, and I tried removing both static and const. 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
Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]
On Sep 5 09:24, Ken Brown via Cygwin wrote: > On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote: > > On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote: > > > Here are the correct commits: > > > > > > 8169e39ab Cygwin: C++17: register keyword is deprecated > > > 3ca80b360 Cygwin: dumper: fix up GCC pragma for g++ 11.2 > > > bdb7991db Cygwin: workaround a g++ 11.2 initialization bug > > > 801120c1f Cygwin: loader script: add DWARF 5 sections > > > d5cc66426 Cygwin: testsuite: avoid "conflicting types" gcc warning > > > c2fe205b5 strstr: avoid warnings > > > 76c2c7a89 ldexp/ldexpf: avoid assembler warning > > > eeeb5650c Cygwin: fix declaration of RtlInitEmptyUnicodeString > > > > > > > > > > > > So there appears to be something wrong with cygwin1.dll > > > > > built with the current build tools (gcc 11.2.0, binutils > > > > > 2.37, not sure what else is relevant). > > > > Wait a minute...I'll bet this is related to the MEM_EXTENDED_PARAMETER > > initialization problem that was dealt with in commit bdb7991db. > > More data: When I run the test case under gdb, it succeeds. When I run it > under strace, I see VirtualAlloc2 in fhandler_dev_zero::mmap failing with > windows error 87. Are the const's I added to the MEM_EXTENDED_PARAMETER data invalid, perhaps? 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
Delivery report
Hello, this is the mail server on mta0.connevate.com. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;mta0.connevate.com X-PowerMTA-VirtualMTA: pmta-vmta0 Received-From-MTA: dns;domain.com (45.154.4.41) Arrival-Date: Mon, 6 Sep 2021 07:38:37 -0500 Final-Recipient: rfc822;cygwin@cygwin.com Action: failed Status: 5.7.1 (delivery not authorized) Remote-MTA: dns;sourceware.org (8.43.85.97) Diagnostic-Code: smtp;550 5.7.1 Blocked by SpamAssassin X-PowerMTA-BounceCategory: spam-related From: cygwin To: cygwin@cygwin.com Subject: Fw: Quote_request Date: 06 Sep 2021 05:38:36 -0700 Message-ID: <20210906053836.349fab5f80f4d...@cygwin.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_NextPart_000_0012_75930AC0.D533F767" -- 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: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
05.09.2021 17:11, Brian Inglis: The suggestion was intended as a tip to ensure *complete* locally rebuilt package contents are installed, Setup has its "from_cwd" installation mode for precisely that reason: installing a local package without the need to create a full install hierarchy and setup.ini files. Due to Windows "improvements", my system upgraded a few years ago is just as "fast" as the 10 year old system it replaced. ;^> Cygwin Setup upgrades can take as long as Windows Update installing the latest patches. If you haven't already, put your Cygwin installation on SSD and exclude the Cygwin root (and local mirror directory) from real-time virus scans. I do monthly updates on slow machines (CPU is a 1.8GHz IvyBridge Celeron) and that takes around two to five minutes depending on how large the update is in any given month (the man-db update happens in the background, so is not part of these figures). -- Achim. (on the road :-) -- 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
