public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
@ 2020-06-15 16:21 Josh Thompson
  2020-06-22 20:11 ` Ken Brown
  0 siblings, 1 reply; 7+ messages in thread
From: Josh Thompson @ 2020-06-15 16:21 UTC (permalink / raw)
  To: cygwin; +Cc: dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Cygwin community,

I'm a developer on the Apache VCL project which is a private cloud management 
platform.  We've used Cygwin for many years to allow VCL management systems to 
ssh in to Windows nodes to manage them.  We're very grateful for the Cygwin 
project and how helpful it has been to us for many years.  :)

We recently noticed a change in double quote (") handling that is causing a 
command we issue to fail.  The command is:

cmd.exe /c "mkdir \"C:/Cygwin/home/root/VCL\""

In 3.1.4-1 and previous versions, the command works as expected.

In 3.1.5-1, it returns this error:

The filename, directory name, or volume label syntax is incorrect.

The command is being issued to a bash shell that is opened over ssh.  I really 
don't know why it was decided to use cmd.exe to launch mkdir instead of just 
using mkdir through bash, but that's how the VCL code currently is.  The 
command is in a utility function that can be passed various paths to create.  
In the case listed above, the escaped quotes wouldn't be needed.  However, if 
the path passed in contained any spaces, the quotes become necessary.

I chatted with jturney and avih on IRC about this (thanks jturney and avih!).  
jturney pointed out using echo instead of mkdir also illustrated the problem.

in 3.1.4:

$ cmd.exe /c "echo \"C:/Cygwin/home/root/VCL\""
"C:/Cygwin/home/root/VCL"

in 3.1.5:

$ cmd.exe /c "echo \"C:/Cygwin/home/root/VCL\""
\"C:/Cygwin/home/root/VCL\"

And, this can be simplified even more to just

3.1.4:
$ cmd.exe /c "echo \""
"

3.1.5:
$ cmd.exe /c "echo \""
\"

avih brought up a valid point that it may now be quoting the quotes since they 
are part of the argument list.  However, I can't come up with the proper 
escaping of things to use mkdir to create a directory with a space in it with 
the new behavior.

jturney asked if I would email this list about the issue.

Thanks for any help!

Josh Thompson
- -- 
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University

my GPG/PGP key can be found on pool.sks-keyservers.net

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCXuegCAAKCRBX8tBw1209
A09tAJ0f2c3/9LaHdYxbprt6IRem8i90ogCfeUNV0SQJFKfIMo8klnr+EiX+oNE=
=Dzm0
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-06-15 16:21 change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1 Josh Thompson
@ 2020-06-22 20:11 ` Ken Brown
  2020-06-24 17:26   ` Josh Thompson
  0 siblings, 1 reply; 7+ messages in thread
From: Ken Brown @ 2020-06-22 20:11 UTC (permalink / raw)
  To: Josh Thompson, cygwin; +Cc: dev

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

On 6/15/2020 12:21 PM, Josh Thompson wrote:
> We recently noticed a change in double quote (") handling that is causing a
> command we issue to fail.  The command is:
[...]
> 3.1.4:
> $ cmd.exe /c "echo \""
> "
> 
> 3.1.5:
> $ cmd.exe /c "echo \""
> \"

I can confirm this change in behavior, and I thought it would be completely 
trivial to do a bisection to find the commit that caused it.  Unfortunately, it 
seems that the issue is somehow tied up with the fact that the toolchain used 
for building the cygwin package was upgraded shortly after the release of 3.1.4.

An attempt to rebuild 3.1.4 with the current toolchain fails because of some 
gcc/binutils changes.  So I applied the attached patches, which were applied to 
the Cygwin git master shortly after the release of 3.1.4, in order to make the 
build succeed.

After installing the rebuilt 3.1.4, however, the cmd.exe call above exhibits the 
"3.1.5" behavior rather than the "3.1.4" behavior.  I can't see anything in the 
patches that would explain this.  I thought maybe it was a compiler optimization 
problem, but rebuilding without optimization doesn't change anything.

I'm stumped.

Ken

[-- Attachment #2: 0001-Cygwin-Makefile.in-add-fno-builtin-execve-CFLAG-when.patch --]
[-- Type: text/plain, Size: 1365 bytes --]

From 5f66c2c756c2b3b43e565e471c82ee4ed05a4adb Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
Date: Wed, 26 Feb 2020 17:02:01 +0100
Subject: [PATCH] Cygwin: Makefile.in: add -fno-builtin-execve CFLAG when
 building exec.o

gcc-9.2.0 has an execve builtin which uses the nothrow attribute.
This results in an error when aliasing execve to _execve for newlib:

exec.cc:88:23: error: 'int _execve(const char*, char* const*, char*
const*)' specifies less restrictive attribute than its target
'int execve(const char*, char* const*, char* const*)': 'nothrow'
[-Werror=missing-attributes]
   88 | EXPORT_ALIAS (execve, _execve) /* For newlib */

Add the -fno-builtin-execve CFLAGS when building exec.o to override
the gcc builtin.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 winsup/cygwin/Makefile.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index ca0633eb8..f273ba793 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -567,6 +567,8 @@ ifeq ($(target_cpu),i686)
 exceptions_CFLAGS:=-fno-omit-frame-pointer
 endif
 endif
+# required since gcc 9.x
+exec_CFLAGS:=-fno-builtin-execve
 
 fhandler_proc_CFLAGS+=-DUSERNAME="\"$(USER)\"" -DHOSTNAME="\"$(HOSTNAME)\""
 fhandler_proc_CFLAGS+=-DGCC_VERSION="\"`$(CC) -v 2>&1 | tail -n 1`\""
-- 
2.27.0


[-- Attachment #3: 0001-Cygwin-posix-timers-fix-uninitialized-variable.patch --]
[-- Type: text/plain, Size: 1246 bytes --]

From 28382c97a5d5fd7366adbf7ce9445b1b4beb02a9 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <corinna@vinschen.de>
Date: Wed, 26 Feb 2020 16:50:34 +0100
Subject: [PATCH] Cygwin: posix timers: fix uninitialized variable

The variable returning the overrun count from the tracker object after
disarming the overrun counter was not correctly initialized.  For some
reason this has only been noticed by gcc-9.2.0, not by the formerly used
gcc-7.4.0.

This problem should not have had any runtime impact.  The method
timer_tracker::disarm_overrun_event is supposed to be called in
lock-step with timer_tracker::arm_overrun_event, which in turn
results in the variable getting a valid value.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
---
 winsup/cygwin/posix_timer.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/posix_timer.cc b/winsup/cygwin/posix_timer.cc
index c0d548fe9..75cd4fa60 100644
--- a/winsup/cygwin/posix_timer.cc
+++ b/winsup/cygwin/posix_timer.cc
@@ -81,7 +81,7 @@ timer_tracker::arm_overrun_event (LONG64 exp_cnt)
 LONG
 timer_tracker::disarm_overrun_event ()
 {
-  LONG ret;
+  LONG ret = 0;
 
   AcquireSRWLockExclusive (&srwlock);
   if (overrun_count != OVR_DISARMED)
-- 
2.27.0


[-- Attachment #4: 0001-Cygwin-Update-dumper-for-bfd-API-changes.patch --]
[-- Type: text/plain, Size: 3247 bytes --]

From ba2f251d439294c7087f3a38a8d407c95cdc5c1e Mon Sep 17 00:00:00 2001
From: Jon Turney <jon.turney@dronecode.org.uk>
Date: Wed, 26 Feb 2020 18:48:51 +0000
Subject: [PATCH] Cygwin: Update dumper for bfd API changes

Update dumper for bfd API changes in binutils 2.34

libbfd doesn't guarantee API stability, so we've just been lucky this
hasn't broken more often.

See binutils commit fd361982.
---
 winsup/utils/dumper.cc   | 30 ++++++++++++++++++++++--------
 winsup/utils/parse_pe.cc |  4 ++++
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/winsup/utils/dumper.cc b/winsup/utils/dumper.cc
index f71bdda8b..226c2283d 100644
--- a/winsup/utils/dumper.cc
+++ b/winsup/utils/dumper.cc
@@ -39,6 +39,20 @@
 
 #define NOTE_NAME_SIZE 16
 
+#ifdef bfd_get_section_size
+/* for bfd < 2.34 */
+#define get_section_name(abfd, sect) bfd_get_section_name (abfd, sect)
+#define get_section_size(sect) bfd_get_section_size(sect)
+#define set_section_size(abfd, sect, size) bfd_set_section_size(abfd, sect, size)
+#define set_section_flags(abfd, sect, flags) bfd_set_section_flags(abfd, sect, flags)
+#else
+/* otherwise bfd >= 2.34 */
+#define get_section_name(afbd, sect) bfd_section_name (sect)
+#define get_section_size(sect) bfd_section_size(sect)
+#define set_section_size(abfd, sect, size) bfd_set_section_size(sect, size)
+#define set_section_flags(abfd, sect, flags) bfd_set_section_flags(sect, flags)
+#endif
+
 typedef struct _note_header
   {
     Elf_External_Note elf_note_header;
@@ -131,7 +145,7 @@ dumper::sane ()
 void
 print_section_name (bfd* abfd, asection* sect, PTR obj)
 {
-  deb_printf (" %s", bfd_get_section_name (abfd, sect));
+  deb_printf (" %s", get_section_name (abfd, sect));
 }
 
 void
@@ -712,10 +726,10 @@ dumper::prepare_core_dump ()
 
       if (p->type == pr_ent_module && status_section != NULL)
 	{
-	  if (!bfd_set_section_size (core_bfd,
-				     status_section,
-				     (bfd_get_section_size (status_section)
-				      + sect_size)))
+	  if (!set_section_size (core_bfd,
+				 status_section,
+				 (get_section_size (status_section)
+				  + sect_size)))
 	    {
 	      bfd_perror ("resizing status section");
 	      goto failed;
@@ -738,8 +752,8 @@ dumper::prepare_core_dump ()
 	  goto failed;
 	}
 
-      if (!bfd_set_section_flags (core_bfd, new_section, sect_flags) ||
-	  !bfd_set_section_size (core_bfd, new_section, sect_size))
+      if (!set_section_flags (core_bfd, new_section, sect_flags) ||
+	  !set_section_size (core_bfd, new_section, sect_size))
 	{
 	  bfd_perror ("setting section attributes");
 	  goto failed;
@@ -823,7 +837,7 @@ dumper::write_core_dump ()
       deb_printf ("writing section type=%u base=%p size=%p flags=%08x\n",
 		  p->type,
 		  p->section->vma,
-		  bfd_get_section_size (p->section),
+		  get_section_size (p->section),
 		  p->section->flags);
 
       switch (p->type)
diff --git a/winsup/utils/parse_pe.cc b/winsup/utils/parse_pe.cc
index 2a388638c..90b5c0b0d 100644
--- a/winsup/utils/parse_pe.cc
+++ b/winsup/utils/parse_pe.cc
@@ -25,6 +25,10 @@
 
 #include "dumper.h"
 
+#ifndef bfd_get_section_size
+#define bfd_get_section_size(sect) bfd_section_size(sect)
+#endif
+
 int
 exclusion::add (LPBYTE mem_base, SIZE_T mem_size)
 {
-- 
2.27.0


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-06-22 20:11 ` Ken Brown
@ 2020-06-24 17:26   ` Josh Thompson
  2020-07-06 11:22     ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Josh Thompson @ 2020-06-24 17:26 UTC (permalink / raw)
  To: Ken Brown; +Cc: cygwin, dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday, June 22, 2020 4:11:35 PM EDT Ken Brown wrote:
> On 6/15/2020 12:21 PM, Josh Thompson wrote:
> > We recently noticed a change in double quote (") handling that is causing
> > a
> 
> > command we issue to fail.  The command is:
> [...]
> 
> > 3.1.4:
> > $ cmd.exe /c "echo \""
> > "
> > 
> > 3.1.5:
> > $ cmd.exe /c "echo \""
> > \"
> 
> I can confirm this change in behavior, and I thought it would be completely
> trivial to do a bisection to find the commit that caused it.  Unfortunately,
> it seems that the issue is somehow tied up with the fact that the toolchain
> used for building the cygwin package was upgraded shortly after the release
> of 3.1.4.
> 
> An attempt to rebuild 3.1.4 with the current toolchain fails because of some
> gcc/binutils changes.  So I applied the attached patches, which were
> applied to the Cygwin git master shortly after the release of 3.1.4, in
> order to make the build succeed.
> 
> After installing the rebuilt 3.1.4, however, the cmd.exe call above exhibits
> the "3.1.5" behavior rather than the "3.1.4" behavior.  I can't see
> anything in the patches that would explain this.  I thought maybe it was a
> compiler optimization problem, but rebuilding without optimization doesn't
> change anything.
> 
> I'm stumped.
> 
> Ken

Hi Ken,

Thanks for your testing on this and for following up.  How strange - I totally 
wouldn't have expected a toolchain upgrade to have changed how quotes get 
handled.

It sounds like it will be difficult to change the quote behavior.  So, we'll 
work to get VCL updated to handle the new behavior.

Thanks,
Josh
- -- 
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University

my GPG/PGP key can be found on pool.sks-keyservers.net

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCXvOMxAAKCRBX8tBw1209
A/ZeAJ0c+FrRV+Sx5xEq5EbTGrkqrRKjggCeLmEG3K46Rx+WQ9Vhu27iPDnrFv4=
=OSZ9
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-06-24 17:26   ` Josh Thompson
@ 2020-07-06 11:22     ` Corinna Vinschen
  2020-07-06 14:14       ` Josh Thompson
  0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2020-07-06 11:22 UTC (permalink / raw)
  To: Josh Thompson; +Cc: Ken Brown, cygwin, dev

On Jun 24 13:26, Josh Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday, June 22, 2020 4:11:35 PM EDT Ken Brown wrote:
> > On 6/15/2020 12:21 PM, Josh Thompson wrote:
> > > We recently noticed a change in double quote (") handling that is causing
> > > a
> > 
> > > command we issue to fail.  The command is:
> > [...]
> > 
> > > 3.1.4:
> > > $ cmd.exe /c "echo \""
> > > "
> > > 
> > > 3.1.5:
> > > $ cmd.exe /c "echo \""
> > > \"
> > 
> > I can confirm this change in behavior, and I thought it would be completely
> > trivial to do a bisection to find the commit that caused it.  Unfortunately,
> > it seems that the issue is somehow tied up with the fact that the toolchain
> > used for building the cygwin package was upgraded shortly after the release
> > of 3.1.4.
> > 
> > An attempt to rebuild 3.1.4 with the current toolchain fails because of some
> > gcc/binutils changes.  So I applied the attached patches, which were
> > applied to the Cygwin git master shortly after the release of 3.1.4, in
> > order to make the build succeed.
> > 
> > After installing the rebuilt 3.1.4, however, the cmd.exe call above exhibits
> > the "3.1.5" behavior rather than the "3.1.4" behavior.  I can't see
> > anything in the patches that would explain this.  I thought maybe it was a
> > compiler optimization problem, but rebuilding without optimization doesn't
> > change anything.
> > 
> > I'm stumped.
> > 
> > Ken
> 
> Hi Ken,
> 
> Thanks for your testing on this and for following up.  How strange - I totally 
> wouldn't have expected a toolchain upgrade to have changed how quotes get 
> handled.
> 
> It sounds like it will be difficult to change the quote behavior.  So, we'll 
> work to get VCL updated to handle the new behavior.

I have a fix for that.  It's a long standing bug, a buffer overrun,
which seem to have had no effect pre-3.1.5 only because the older GCC
toolchain had a subtily different stack allocation strategy.

I uploaded developer snapshots to https://cygwin.com/snapshots/
for testing.  Please give this a try and report back.

If this fixes your problem, the bug is serious enough to qualify for
a Cygwin 3.1.6 RSN.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-07-06 11:22     ` Corinna Vinschen
@ 2020-07-06 14:14       ` Josh Thompson
  2020-07-06 18:15         ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Josh Thompson @ 2020-07-06 14:14 UTC (permalink / raw)
  To: cygwin; +Cc: dev

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

> > On Monday, June 22, 2020 4:11:35 PM EDT Ken Brown wrote:
> > > On 6/15/2020 12:21 PM, Josh Thompson wrote:
> > > > We recently noticed a change in double quote (") handling that is
> > > > causing
> > > > a
> > > 
> > > > command we issue to fail.  The command is:
> > > [...]
> > > 
> > > > 3.1.4:
> > > > $ cmd.exe /c "echo \""
> > > > "
> > > > 
> > > > 3.1.5:
> > > > $ cmd.exe /c "echo \""
> > > > \"
> > > 
> > > I can confirm this change in behavior, and I thought it would be
> > > completely
> > > trivial to do a bisection to find the commit that caused it. 
> > > Unfortunately, it seems that the issue is somehow tied up with the fact
> > > that the toolchain used for building the cygwin package was upgraded
> > > shortly after the release of 3.1.4.
> > > 
> > > An attempt to rebuild 3.1.4 with the current toolchain fails because of
> > > some gcc/binutils changes.  So I applied the attached patches, which
> > > were applied to the Cygwin git master shortly after the release of
> > > 3.1.4, in order to make the build succeed.
> > > 
> > > After installing the rebuilt 3.1.4, however, the cmd.exe call above
> > > exhibits the "3.1.5" behavior rather than the "3.1.4" behavior.  I
> > > can't see anything in the patches that would explain this.  I thought
> > > maybe it was a compiler optimization problem, but rebuilding without
> > > optimization doesn't change anything.
> > > 
> > > I'm stumped.
> > > 
> > > Ken
> > 
> > Hi Ken,
> > 
> > Thanks for your testing on this and for following up.  How strange - I
> > totally wouldn't have expected a toolchain upgrade to have changed how
> > quotes get handled.
> > 
> > It sounds like it will be difficult to change the quote behavior.  So,
> > we'll work to get VCL updated to handle the new behavior.
> 
> I have a fix for that.  It's a long standing bug, a buffer overrun,
> which seem to have had no effect pre-3.1.5 only because the older GCC
> toolchain had a subtily different stack allocation strategy.
> 
> I uploaded developer snapshots to https://cygwin.com/snapshots/
> for testing.  Please give this a try and report back.
> 
> If this fixes your problem, the bug is serious enough to qualify for
> a Cygwin 3.1.6 RSN.
> 
> 
> Thanks,
> Corinna

Hi Corinna,

Thank you for this!  I can confirm that replacing cygwin1.dll with the 
cygwin1-20200706.dll that you uploaded to the snapshot site fixes the quote 
issue.

I upgraded an installation I had to 3.1.5-1 and tested that I was seeing the 
problem by running

cmd.exe /c "echo \""
\"

Next, I downloaded, uncompressed, and overwrote cygwin1.dll with 
cygwin1-20200706.dll and tested again

cmd.exe /c "echo \""
"

Great job working through that issue.

Josh
-- 
-------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found on pool.sks-keyservers.net

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-07-06 14:14       ` Josh Thompson
@ 2020-07-06 18:15         ` Corinna Vinschen
  2020-07-21 16:45           ` Josh Thompson
  0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2020-07-06 18:15 UTC (permalink / raw)
  To: Josh Thompson; +Cc: cygwin, dev

On Jul  6 10:14, Josh Thompson wrote:
> > > On Monday, June 22, 2020 4:11:35 PM EDT Ken Brown wrote:
> > > > On 6/15/2020 12:21 PM, Josh Thompson wrote:
> > > > [...]
> > > > > 3.1.4:
> > > > > $ cmd.exe /c "echo \""
> > > > > "
> > > > > 
> > > > > 3.1.5:
> > > > > $ cmd.exe /c "echo \""
> > > > > \"
> > > > [...]
> > > > After installing the rebuilt 3.1.4, however, the cmd.exe call above
> > > > exhibits the "3.1.5" behavior rather than the "3.1.4" behavior.  I
> > > > can't see anything in the patches that would explain this.  I thought
> > > > maybe it was a compiler optimization problem, but rebuilding without
> > > > optimization doesn't change anything.
> > > [...]
> > > It sounds like it will be difficult to change the quote behavior.  So,
> > > we'll work to get VCL updated to handle the new behavior.
> > 
> > I have a fix for that.  It's a long standing bug, a buffer overrun,
> > which seem to have had no effect pre-3.1.5 only because the older GCC
> > toolchain had a subtily different stack allocation strategy.
> > 
> > I uploaded developer snapshots to https://cygwin.com/snapshots/
> > for testing.  Please give this a try and report back.
> > 
> > If this fixes your problem, the bug is serious enough to qualify for
> > a Cygwin 3.1.6 RSN.
> 
> Thank you for this!  I can confirm that replacing cygwin1.dll with the 
> cygwin1-20200706.dll that you uploaded to the snapshot site fixes the quote 
> issue.
> 
> I upgraded an installation I had to 3.1.5-1 and tested that I was seeing the 
> problem by running
> 
> cmd.exe /c "echo \""
> \"
> 
> Next, I downloaded, uncompressed, and overwrote cygwin1.dll with 
> cygwin1-20200706.dll and tested again
> 
> cmd.exe /c "echo \""
> "
> 
> Great job working through that issue.

Thanks for testing and confirming.  Expect 3.1.6 in the next couple
of days.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1
  2020-07-06 18:15         ` Corinna Vinschen
@ 2020-07-21 16:45           ` Josh Thompson
  0 siblings, 0 replies; 7+ messages in thread
From: Josh Thompson @ 2020-07-21 16:45 UTC (permalink / raw)
  To: cygwin; +Cc: dev

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

On Monday, July 6, 2020 2:15:49 PM EDT Corinna Vinschen wrote:
> On Jul  6 10:14, Josh Thompson wrote:
> > > > On Monday, June 22, 2020 4:11:35 PM EDT Ken Brown wrote:
> > > > > On 6/15/2020 12:21 PM, Josh Thompson wrote:
> > > > > [...]
> > > > > 
> > > > > > 3.1.4:
> > > > > > $ cmd.exe /c "echo \""
> > > > > > "
> > > > > > 
> > > > > > 3.1.5:
> > > > > > $ cmd.exe /c "echo \""
> > > > > > \"
> > > > > 
> > > > > [...]
> > > > > After installing the rebuilt 3.1.4, however, the cmd.exe call above
> > > > > exhibits the "3.1.5" behavior rather than the "3.1.4" behavior.  I
> > > > > can't see anything in the patches that would explain this.  I
> > > > > thought
> > > > > maybe it was a compiler optimization problem, but rebuilding without
> > > > > optimization doesn't change anything.
> > > > 
> > > > [...]
> > > > It sounds like it will be difficult to change the quote behavior.  So,
> > > > we'll work to get VCL updated to handle the new behavior.
> > > 
> > > I have a fix for that.  It's a long standing bug, a buffer overrun,
> > > which seem to have had no effect pre-3.1.5 only because the older GCC
> > > toolchain had a subtily different stack allocation strategy.
> > > 
> > > I uploaded developer snapshots to https://cygwin.com/snapshots/
> > > for testing.  Please give this a try and report back.
> > > 
> > > If this fixes your problem, the bug is serious enough to qualify for
> > > a Cygwin 3.1.6 RSN.
> > 
> > Thank you for this!  I can confirm that replacing cygwin1.dll with the
> > cygwin1-20200706.dll that you uploaded to the snapshot site fixes the
> > quote
> > issue.
> > 
> > I upgraded an installation I had to 3.1.5-1 and tested that I was seeing
> > the problem by running
> > 
> > cmd.exe /c "echo \""
> > \"
> > 
> > Next, I downloaded, uncompressed, and overwrote cygwin1.dll with
> > cygwin1-20200706.dll and tested again
> > 
> > cmd.exe /c "echo \""
> > "
> > 
> > Great job working through that issue.
> 
> Thanks for testing and confirming.  Expect 3.1.6 in the next couple
> of days.
> 

Hi Corinna,

I just wanted to follow up to confirm that upgrading to 3.1.6-1 fixes the 
problem for us.  Thanks for your help!

Josh
-- 
-------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

Josh_Thompson@ncsu.edu
919-515-5323

my GPG/PGP key can be found on pool.sks-keyservers.net

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-07-21 16:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 16:21 change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1 Josh Thompson
2020-06-22 20:11 ` Ken Brown
2020-06-24 17:26   ` Josh Thompson
2020-07-06 11:22     ` Corinna Vinschen
2020-07-06 14:14       ` Josh Thompson
2020-07-06 18:15         ` Corinna Vinschen
2020-07-21 16:45           ` Josh Thompson

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).