[PATCH] cygwin: export wmempcpy

[Yaakov Selkowitz]

Signed-off-by: Yaakov Selkowitz 
---
Obviously this depends on the newlib implementation patch.

 winsup/cygwin/common.din   | 1 +
 winsup/cygwin/include/cygwin/version.h | 3 ++-
 winsup/doc/posix.xml   | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/common.din b/winsup/cygwin/common.din
index a482cf2b7..14b9c2c18 100644
--- a/winsup/cygwin/common.din
+++ b/winsup/cygwin/common.din
@@ -1609,6 +1609,7 @@ wmemchr NOSIGFE
 wmemcmp NOSIGFE
 wmemcpy NOSIGFE
 wmemmove NOSIGFE
+wmempcpy NOSIGFE
 wmemset NOSIGFE
 wordexp NOSIGFE
 wordfree NOSIGFE
diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index d8bb3ee44..7510f42b0 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -489,12 +489,13 @@ details. */
__stack_chk_fail, __stack_chk_guard, __stpcpy_chk, __stpncpy_chk,
__strcat_chk, __strcpy_chk, __strncat_chk, __strncpy_chk,
__vsnprintf_chk, __vsprintf_chk.
+  321: Export wmempcpy.
 
   Note that we forgot to bump the api for ualarm, strtoll, strtoull,
   sigaltstack, sethostname. */
 
 #define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 320
+#define CYGWIN_VERSION_API_MINOR 321
 
 /* There is also a compatibity version number associated with the shared memory
regions.  It is incremented when incompatible changes are made to the shared
diff --git a/winsup/doc/posix.xml b/winsup/doc/posix.xml
index c99e003ba..ab574300f 100644
--- a/winsup/doc/posix.xml
+++ b/winsup/doc/posix.xml
@@ -1396,6 +1396,7 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008).
 wcstoll_l
 wcstoul_l
 wcstoull_l
+wmempcpy
 
 
 
-- 
2.15.0

Re: sort utility goes berzerk (x86_64)

[Houder]

On Wed, 29 Nov 2017 15:39:45, Brian Inglis wrote:

> > On 2017-11-25 14:23, Houder wrote:
> > > Hi,
> > >
> > > Anyone seeing this as well? sort goes berzerk on my system when piped
> > > into
> > > head (or less) when it is fed with a 'specially prepared' input file.
> > >
> > >� - only happens on x86_64
> > >� - does not happen for 'LC_COLLATE=C sort tt | head'
> > >
> > > 'specially prepared' input file? (see bottom of post).
> >
> > Anyone ** NOT ** seeing this?

Brian and Achim, thanks for the interest in this peculiar problems.

Currently my Windows 7 is not much of a tool to me. I have ripped out about
everything in an attempt to find the cause of the weird behaviour of sort.

Ripped out everything? Visual Studio (and anything related to it), Firefox,
F-Secure (virusscanner), etc., etc., etc. ...

However, sort still behaves in the same weird manner.

That is, NOT if invoked as follows (in a script):

#!/bin/bash
trap "" PIPE # make sort ignore the SIGPIPE signal
export LC_COLLATE=en_US.UTF-8
exec /usr/bin/sort ${1+"$@"} 2> /dev/null

.. meaning if SIGPIPE is ignored by sort (which would kill it otherwise),
it will notice the broken pipe while writing, and terminate itself.

What also amazes me, is the stack dump of the 'sort thread', which I got
using the Process Explorer by Mark R.

ntoskrnl.exe!memset+0x61a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xbd0 < ?
ntoskrnl.exe!PoStartNextPowerIrp+0x186d < ?
cygwin1.dll!reent_data+0x5f0
cygwin1.dll!acl_get_perm+0x9aa1
cygwin1.dll!_getreent+0x1097
sort.exe+0x5319
sort.exe+0x103e0
cygwin1.dll!cygwin_dll_init+0x11c2
cygwin1.dll!setprogname+0x35c3
cygwin1.dll!setprogname+0x3674

This is the stack dump of sort when it occupies the core completely, and
has become unresponsive.

I do not know anything about the internals of Windows, but it amazes me
to see 'a power related function call' on the stack of sort.

> Have you checked for permissions problems on $TMPDIR if set, or /tmp?

Yes, all these things have been checked by me ...

Henri

(message sent from Fedora, as I cannot currently use Windows 7)

=


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: sort utility goes berzerk (x86_64)

[Brian Inglis]

On 2017-11-28 10:12, Houder wrote:
> On 2017-11-28 14:37, Doug Henderson wrote:
> 
> On 2017-11-25 14:23, Houder wrote:
> > Hi,
> >
> > Anyone seeing this as well? sort goes berzerk on my system when piped
> > into
> > head (or less) when it is fed with a 'specially prepared' input file.
> >
> >  - only happens on x86_64
> >  - does not happen for 'LC_COLLATE=C sort tt | head'
> >
> > 'specially prepared' input file? (see bottom of post).
>
> Anyone ** NOT ** seeing this?
> 
>> Q4. After you kill a hung sort, are there files left over in /tmp? I
>> am wondering if the problem files are too big to do an in-core sort,
>> and something goes wrong when it switches to a temp file sort, but not
>> for smaller or larger input files where it correctly predicts which
>> type of sort it needs to do. Possibly using the "--buffer-size=N"
>> option will change the behavior, making smaller input files fail and
>> failing ones work.

> sort should not fail in the way it does; it does not on "Cygwin/x86" on
> my machine; it does not on Linux (Fedora 24) (same machine).

No problems with many sizes, Cygwin or Windows sort, under bash or dash.

Have you checked for permissions problems on $TMPDIR if set, or /tmp?
My TMPDIR=/tmp - try:
$ ls -dl$TMPDIR /tmp
drwxrwxrwt+ 1  Users 0 Nov 29 15:24 /tmp
...
$ getfacl   $TMPDIR /tmp
# file: /tmp
# owner: 
# group: Users
# flags: --t
user::rwx
group::rwx
other:rwx
default:user::rwx
default:group::r-x
default:other:r-x
...
$ icacls `cygpath -m $TMPDIR`
C://tmp NULL SID:(DENY)(Rc,S,RD)
  \:(F)
  BUILTIN\Users:(RX,W)
  Everyone:(RX,W)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(RX)
  Everyone:(OI)(CI)(IO)(RX)
$ icacls `cygpath -m /tmp`
...

and maybe try specifying an explicit temp dir using e.g. sort -T $HOME/

Maybe also check if any limits:
$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
open files  (-n) 256
pipe size(512 bytes, -p) 8
stack size  (kbytes, -s) 2032
cpu time   (seconds, -t) unlimited
max user processes  (-u) 256
virtual memory  (kbytes, -v) unlimited

Maybe try reinstalling coreutils in a standalone setup run?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 29/11/2017 21:34, Ivan Gagis wrote:

What is that timestamp? Is it when the package was uploaded?


Sorry, by timestamp, I just mean the mtime of the archive file.


Then it should not be possible, because lower version definitely was
uploaded earlier than higher version package.

Where are those timestamps kept? Hint files does not contain any
timestamp and setup.ini only has its global timestamp, but not
per-package timestamps.

Do you have any suggestion of how to fix this?


Assuming you've found a bug, I need some more details to enable me to 
reproduce it, before I can fix it...



2017-11-29 18:52 GMT+02:00 Jon Turney:

On 29/11/2017 15:06, Ivan Gagis wrote:


I have an overlay cygwin repo where I publish my packages.

Recently I started getting errors from mksetupini script:

"
mksetupini: package 'mypackage' version '0.4.38-1' is most recent
non-test version, but version '0.4.43-1' is curr:
mksetupini: package set has errors, not writing setup.ini
"

there was no such errors before. And I don't have "test:" in any hint
files of my packages, so no I dea why it thinks that some versions are
non-test and curr is test?



It's not saying any versions are test.


Can you explain what this actually means?



"most recent" means "latest timestamp"

So this is telling you that 0.4.38-1 is the non-test version which has the
most recent timestamp, but 0.4.43-1 is curr: (because it's the highest
non-test version)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: wcwidth / Unicode inconsistent

[ML]

hope to see this in Cygwin soon, I've been running a custom compilation
of cygwin1.dll for awhile using some of Thomas's patches. 

On Wed, Nov 29, 2017, at 03:44 PM, Corinna Vinschen wrote:
> On Nov 29 20:56, Thomas Wolff wrote:
> > May I kindly remind of https://cygwin.com/ml/cygwin/2017-07/msg00366.html,
> > for which my patch proposal is still pending on the newlib mailing list?
> 
> You may want to ping the patch on the newlib ML.
> 
> I actually forgot about this patch, sorry.
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: wcwidth / Unicode inconsistent

[Corinna Vinschen]

On Nov 29 20:56, Thomas Wolff wrote:
> May I kindly remind of https://cygwin.com/ml/cygwin/2017-07/msg00366.html,
> for which my patch proposal is still pending on the newlib mailing list?

You may want to ping the patch on the newlib ML.

I actually forgot about this patch, sorry.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH 1/2] cygwin: add Object Size Checking to sys/poll.h

[Corinna Vinschen]

On Nov 29 11:45, Yaakov Selkowitz wrote:
> Signed-off-by: Yaakov Selkowitz 
> ---
>  winsup/cygwin/include/ssp/poll.h | 26 ++
>  winsup/cygwin/include/sys/poll.h |  4 
>  2 files changed, 30 insertions(+)
>  create mode 100644 winsup/cygwin/include/ssp/poll.h
> 
> diff --git a/winsup/cygwin/include/ssp/poll.h 
> b/winsup/cygwin/include/ssp/poll.h
> new file mode 100644
> index 0..831e626d6
> --- /dev/null
> +++ b/winsup/cygwin/include/ssp/poll.h
> @@ -0,0 +1,26 @@
> +#ifndef _SSP_POLL_H_
> +#define _SSP_POLL_H_
> +
> +#include 
> +
> +#if __SSP_FORTIFY_LEVEL > 0
> +__BEGIN_DECLS
> +
> +__ssp_decl(int, poll, (struct pollfd *__fds, nfds_t __nfds, int __timeout))
> +{
> +  __ssp_check (__fds, __nfds * sizeof(*__fds), __ssp_bos);
> +  return __ssp_real_poll (__fds, __nfds, __timeout);
> +}
> +
> +#if __GNU_VISIBLE
> +__ssp_decl(int, ppoll, (struct pollfd *__fds, nfds_t __nfds, const struct 
> timespec *__timeout_ts, const sigset_t *__sigmask))
> +{
> +  __ssp_check (__fds, __nfds * sizeof(*__fds), __ssp_bos);
> +  return __ssp_real_ppoll (__fds, __nfds, __timeout_ts, __sigmask);
> +}
> +#endif
> +
> +__END_DECLS
> +
> +#endif /* __SSP_FORTIFY_LEVEL > 0 */
> +#endif /* _SSP_POLL_H_ */
> diff --git a/winsup/cygwin/include/sys/poll.h 
> b/winsup/cygwin/include/sys/poll.h
> index 0da4c3f03..65822edb3 100644
> --- a/winsup/cygwin/include/sys/poll.h
> +++ b/winsup/cygwin/include/sys/poll.h
> @@ -47,4 +47,8 @@ extern int ppoll __P ((struct pollfd *fds, nfds_t nfds,
>  
>  __END_DECLS
>  
> +#if __SSP_FORTIFY_LEVEL > 0
> +#include 
> +#endif
> +
>  #endif /* _SYS_POLL_H */
> -- 
> 2.15.0

ACK to both patches.

For patch series, please add a cover letter, it's not too much effort
and clearer.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

wcwidth / Unicode inconsistent

[Thomas Wolff]

May I kindly remind of https://cygwin.com/ml/cygwin/2017-07/msg00366.html,
for which my patch proposal is still pending on the newlib mailing list?
While it's not as urgent anymore for mintty, where I've introduced a 
native width option meanwhile (Charwidth, corresponding to xterm 
-mk_width), it's not the best way to tune character width as it makes it 
inconsistent with wcwidth; also other applications might benefit from 
the option to update wcwidth seamlessly with each Unicode version.

Thomas

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: sort utility goes berzerk (x86_64)

[Achim Gratz]

Houder writes:
> No, I have not executed rebaseall. The reason is, that I have
> "reinstalled" Cygwin twice now, starting with an empty repo and an
> empty root directory.

I have seen the initial rebaseall after a fresh install go wrong due to
antivirus interference.  Triggering another full rebase cleared that up,
presumably because the files were no longer marked as "new" by the
antivirus.  In one particular instance I've had to manually scan the
Cygwin installation folder before things would start working correctly.

Another thing you can check is the memory map of your terminal session,
then write some script that forks a few times and have the process at
the end of the fork chain dump its own map or maybe start a shell inside
Emacs and dumpt the map there.  Then check for any conspicuous
differences, especially non-Cygwin-DLL that get suddenly injected.

YMMV.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[PATCH 2/2] cygwin: add Object Size Checking to sys/socket.h

[Yaakov Selkowitz]

Signed-off-by: Yaakov Selkowitz 
---
 winsup/cygwin/include/ssp/socket.h | 20 
 winsup/cygwin/include/sys/socket.h |  4 
 2 files changed, 24 insertions(+)
 create mode 100644 winsup/cygwin/include/ssp/socket.h

diff --git a/winsup/cygwin/include/ssp/socket.h 
b/winsup/cygwin/include/ssp/socket.h
new file mode 100644
index 0..3abbddbdf
--- /dev/null
+++ b/winsup/cygwin/include/ssp/socket.h
@@ -0,0 +1,20 @@
+#ifndef _SSP_SOCKET_H_
+#define _SSP_SOCKET_H_
+
+#include 
+
+#if __SSP_FORTIFY_LEVEL > 0
+__BEGIN_DECLS
+
+__ssp_redirect0(ssize_t, recv, \
+(int __fd, void *__buf, size_t __len, int __flags), \
+(__fd, __buf, __len, __flags));
+
+__ssp_redirect0(ssize_t, recvfrom, \
+(int __fd, void *__buf, size_t __len, int __flags, struct sockaddr 
*__from, socklen_t *__fromlen), \
+(__fd, __buf, __len, __flags, __from, __fromlen));
+
+__END_DECLS
+
+#endif /* __SSP_FORTIFY_LEVEL > 0 */
+#endif /* _SSP_SOCKET_H_ */
diff --git a/winsup/cygwin/include/sys/socket.h 
b/winsup/cygwin/include/sys/socket.h
index 8bab35b68..9e897a9ff 100644
--- a/winsup/cygwin/include/sys/socket.h
+++ b/winsup/cygwin/include/sys/socket.h
@@ -50,4 +50,8 @@ extern "C"
 };
 #endif
 
+#if __SSP_FORTIFY_LEVEL > 0
+#include 
+#endif
+
 #endif /* _SYS_SOCKET_H */
-- 
2.15.0

[PATCH 1/2] cygwin: add Object Size Checking to sys/poll.h

[Yaakov Selkowitz]

Signed-off-by: Yaakov Selkowitz 
---
 winsup/cygwin/include/ssp/poll.h | 26 ++
 winsup/cygwin/include/sys/poll.h |  4 
 2 files changed, 30 insertions(+)
 create mode 100644 winsup/cygwin/include/ssp/poll.h

diff --git a/winsup/cygwin/include/ssp/poll.h b/winsup/cygwin/include/ssp/poll.h
new file mode 100644
index 0..831e626d6
--- /dev/null
+++ b/winsup/cygwin/include/ssp/poll.h
@@ -0,0 +1,26 @@
+#ifndef _SSP_POLL_H_
+#define _SSP_POLL_H_
+
+#include 
+
+#if __SSP_FORTIFY_LEVEL > 0
+__BEGIN_DECLS
+
+__ssp_decl(int, poll, (struct pollfd *__fds, nfds_t __nfds, int __timeout))
+{
+  __ssp_check (__fds, __nfds * sizeof(*__fds), __ssp_bos);
+  return __ssp_real_poll (__fds, __nfds, __timeout);
+}
+
+#if __GNU_VISIBLE
+__ssp_decl(int, ppoll, (struct pollfd *__fds, nfds_t __nfds, const struct 
timespec *__timeout_ts, const sigset_t *__sigmask))
+{
+  __ssp_check (__fds, __nfds * sizeof(*__fds), __ssp_bos);
+  return __ssp_real_ppoll (__fds, __nfds, __timeout_ts, __sigmask);
+}
+#endif
+
+__END_DECLS
+
+#endif /* __SSP_FORTIFY_LEVEL > 0 */
+#endif /* _SSP_POLL_H_ */
diff --git a/winsup/cygwin/include/sys/poll.h b/winsup/cygwin/include/sys/poll.h
index 0da4c3f03..65822edb3 100644
--- a/winsup/cygwin/include/sys/poll.h
+++ b/winsup/cygwin/include/sys/poll.h
@@ -47,4 +47,8 @@ extern int ppoll __P ((struct pollfd *fds, nfds_t nfds,
 
 __END_DECLS
 
+#if __SSP_FORTIFY_LEVEL > 0
+#include 
+#endif
+
 #endif /* _SYS_POLL_H */
-- 
2.15.0

[newlib-cygwin] cygwin: create libssp compatibility import library

[Yaakov Selkowitz]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=552a20ab4e2736d7cbd0293f8a69d7fbf8761fa8

commit 552a20ab4e2736d7cbd0293f8a69d7fbf8761fa8
Author: Yaakov Selkowitz 
Date:   Mon Nov 27 23:56:30 2017 -0600

cygwin: create libssp compatibility import library

Signed-off-by: Yaakov Selkowitz 

Diff:
---
 winsup/cygwin/Makefile.in | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index a70f28d..c1de26c 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -540,7 +540,7 @@ endif
 API_VER:=$(srcdir)/include/cygwin/version.h
 
 LIB_NAME:=libcygwin.a
-SUBLIBS:=libpthread.a libutil.a ${CURDIR}/libm.a ${CURDIR}/libc.a libdl.a 
libresolv.a librt.a libacl.a
+SUBLIBS:=libpthread.a libutil.a ${CURDIR}/libm.a ${CURDIR}/libc.a libdl.a 
libresolv.a librt.a libacl.a libssp.a
 EXTRALIBS:=libautomode.a libbinmode.a libtextmode.a libtextreadmode.a
 INSTOBJS:=automode.o binmode.o textmode.o textreadmode.o
 TARGET_LIBS:=$(LIB_NAME) $(CYGWIN_START) $(GMON_START) $(LIBGMON_A) $(SUBLIBS) 
$(INSTOBJS) $(EXTRALIBS)
@@ -745,6 +745,9 @@ librt.a: ${LIB_NAME} posix_ipc.o
 libacl.a: ${LIB_NAME} sec_posixacl.o
${speclib} ${@F}
 
+libssp.a: ${LIB_NAME} $(newlib_build)/libc/ssp/lib.a
+   ${speclib} ${@F}
+
 ${EXTRALIBS}: lib%.a: %.o
$(AR) cru $@ $?

[newlib-cygwin] cygwin: export SSP functions

[Yaakov Selkowitz]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=6a848db44242a24d6570ef7994918c66ce483fd2

commit 6a848db44242a24d6570ef7994918c66ce483fd2
Author: Yaakov Selkowitz 
Date:   Mon Nov 27 23:55:11 2017 -0600

cygwin: export SSP functions

Signed-off-by: Yaakov Selkowitz 

Diff:
---
 winsup/cygwin/common.din   | 19 +++
 winsup/cygwin/include/cygwin/version.h |  7 ++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/common.din b/winsup/cygwin/common.din
index 55fa9b1..a482cf2 100644
--- a/winsup/cygwin/common.din
+++ b/winsup/cygwin/common.din
@@ -7,6 +7,7 @@ __cygwin_user_data DATA
 __mb_cur_max DATA
 __progname DATA
 __rcmd_errstr DATA
+__stack_chk_guard DATA
 _check_for_executable DATA
 _ctype_ DATA
 _daylight DATA
@@ -42,6 +43,7 @@ __assertfail NOSIGFE
 __b64_ntop NOSIGFE
 __b64_pton NOSIGFE
 __bsd_qsort_r NOSIGFE
+__chk_fail SIGFE
 __cxa_atexit = cygwin__cxa_atexit SIGFE
 __cxa_finalize SIGFE
 __dn_comp SIGFE
@@ -62,6 +64,7 @@ __fwritable NOSIGFE
 __fwriting NOSIGFE
 __getpagesize = getpagesize SIGFE
 __getreent NOSIGFE
+__gets_chk SIGFE
 __gnu_basename NOSIGFE
 __infinity NOSIGFE
 __isinfd = isinf NOSIGFE
@@ -72,7 +75,11 @@ __locale_ctype_ptr NOSIGFE
 __locale_ctype_ptr_l NOSIGFE
 __locale_mb_cur_max NOSIGFE
 __main NOSIGFE
+__memcpy_chk NOSIGFE
+__memmove_chk NOSIGFE
 __mempcpy = mempcpy NOSIGFE
+__mempcpy_chk NOSIGFE
+__memset_chk NOSIGFE
 __opendir_with_d_ino SIGFE
 __res_close SIGFE
 __res_init SIGFE
@@ -92,10 +99,22 @@ __res_state SIGFE
 __signbitd NOSIGFE
 __signbitf NOSIGFE
 __signgam NOSIGFE
+__snprintf_chk SIGFE
+__sprintf_chk SIGFE
 __srget SIGFE
 __srget_r SIGFE
+__stack_chk_fail SIGFE
+__stack_chk_fail_local = __stack_chk_fail SIGFE
+__stpcpy_chk NOSIGFE
+__stpncpy_chk NOSIGFE
+__strcat_chk NOSIGFE
+__strcpy_chk NOSIGFE
+__strncat_chk NOSIGFE
+__strncpy_chk NOSIGFE
 __swbuf SIGFE
 __swbuf_r SIGFE
+__vsnprintf_chk SIGFE
+__vsprintf_chk SIGFE
 __wrap__ZdaPv NOSIGFE   # void operator delete[](void *p) throw()
 __wrap__ZdaPvRKSt9nothrow_t NOSIGFE # void operator delete[](void *p, const 
std::nothrow_t ) throw()
 __wrap__ZdlPv NOSIGFE   # void operator delete(void *p) throw()
diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index 8b85f86..d8bb3ee 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -484,12 +484,17 @@ details. */
   317: Export renameat2.
   318: Export strnstr.
   319: Define O_TMPFILE, O_NOATIME.
+  320: Export __chk_fail, __gets_chk, __memcpy_chk, __memmove_chk,
+   __mempcpy_chk, __memset_chk, __snprintf_chk, __sprintf_chk,
+   __stack_chk_fail, __stack_chk_guard, __stpcpy_chk, __stpncpy_chk,
+   __strcat_chk, __strcpy_chk, __strncat_chk, __strncpy_chk,
+   __vsnprintf_chk, __vsprintf_chk.
 
   Note that we forgot to bump the api for ualarm, strtoll, strtoull,
   sigaltstack, sethostname. */
 
 #define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 319
+#define CYGWIN_VERSION_API_MINOR 320
 
 /* There is also a compatibity version number associated with the shared memory
regions.  It is incremented when incompatible changes are made to the shared

Re: mksetupini does not return error code

[Jon Turney]

On 29/11/2017 14:58, Ivan Gagis wrote:

Hi,

I found that in case packages validation fails the mksetup script just
returns success, though it prints a line in the console saying
"mksetupini: package set has errors, not writing setup.ini".

I think it should return some error code so that it would not be
considered as success by CI scripts where mksetupini is called from.

The problematic lines are as following:

https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/mksetupini.py;h=f24e4c5751e1f7e13516e8689c041403ba1f8d38;hb=HEAD#l63
returns nothing, should return non-zero error code.

https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/mksetupini.py;h=f24e4c5751e1f7e13516e8689c041403ba1f8d38;hb=HEAD#l118
returns nothing, should return result of do_main().

I'm not familiar with python, so I don't submit a patch, but even
without knowing python it is clearly seen that the errors are not
returned properly.


Yeah, this is a bit of an oversight.  Thanks for pointing it out.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: mksetupini fails validating packages because curr is test

[Jon Turney]

On 29/11/2017 15:06, Ivan Gagis wrote:

I have an overlay cygwin repo where I publish my packages.

Recently I started getting errors from mksetupini script:

"
mksetupini: package 'mypackage' version '0.4.38-1' is most recent
non-test version, but version '0.4.43-1' is curr:
mksetupini: package set has errors, not writing setup.ini
"

there was no such errors before. And I don't have "test:" in any hint
files of my packages, so no I dea why it thinks that some versions are
non-test and curr is test?


It's not saying any versions are test.


Can you explain what this actually means?


"most recent" means "latest timestamp"

So this is telling you that 0.4.38-1 is the non-test version which has 
the most recent timestamp, but 0.4.43-1 is curr: (because it's the 
highest non-test version)


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 2.9.0 regtool x64 exception error (W10)

[ViOLeT]

(gdb) target exec regtool -w get "\HKCR\c\205\216c\205\216c\205\216c\205\216
regtool -w get "\HKCR\c▒▒c▒▒c▒▒c▒▒": No such file or directory.

The text are not written correctly, but there are no errors.

Mysterious error. T-T
There is an error in the Korean OS.

See error : mediafire.com/file/7vcaa4xrrcdbis7/test.avi

2017-11-30 1:15 GMT+09:00 Corinna Vinschen :
> On Nov 30 00:41, ViOLeT wrote:
>> # OS Language
>> Korean (Asia), CHCP Code 949
>>
>> # Locale Code
>> LANG=
>> LC_CTYPE="C.UTF-8"
>> LC_NUMERIC="C.UTF-8"
>> LC_TIME="C.UTF-8"
>> LC_COLLATE="C.UTF-8"
>> LC_MONETARY="C.UTF-8"
>> LC_MESSAGES="C.UTF-8"
>> LC_ALL=
>>
>> Is it an operating system language issue?
>
> I honestly don't know.  You see me really puzzled by this problem.  I
> tried your examples again in mintty and a Windows console set to CP 949
> with the locale set to "C.UTF-8", but it works fine for me in all cases.
>
> Could you try to debug this problem?  If you install gdb and the
> cygwin-debuginfo package, you should be able to step through the code
> of regtool (with a bit of jumping around due to compiler optimization)
> and see what happens.
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: mesa 17.2.6-1

[Daniele BADIALI]

REMOVE

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 2.9.0 regtool x64 exception error (W10)

[Corinna Vinschen]

On Nov 30 00:41, ViOLeT wrote:
> # OS Language
> Korean (Asia), CHCP Code 949
> 
> # Locale Code
> LANG=
> LC_CTYPE="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=
> 
> Is it an operating system language issue?

I honestly don't know.  You see me really puzzled by this problem.  I
tried your examples again in mintty and a Windows console set to CP 949
with the locale set to "C.UTF-8", but it works fine for me in all cases.

Could you try to debug this problem?  If you install gdb and the
cygwin-debuginfo package, you should be able to step through the code
of regtool (with a bit of jumping around due to compiler optimization)
and see what happens.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Cygwin 2.9.0 regtool x64 exception error (W10)

[ViOLeT]

# OS Language
Korean (Asia), CHCP Code 949

# Locale Code
LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

Is it an operating system language issue?

2017-11-29 18:29 GMT+09:00 Corinna Vinschen :
> Hi ViOLeT,
>
> On Nov 29 15:33, ViOLeT wrote:
>> Hello.
>>
>> Cygwin 2.9.0 regtool x64 exception error (W10) reporting. (But it seems to
>> be an error in all (2.9.0 lower) versions.)
>>
>> Using the Unicode causes an exception error.
>> But, regtool x86 is no error occurs.
>>
>> *Example :*
>> regtool.exe -w get "\HKCR\하하하"
>> regtool.exe -w get "\HKCR\家"
>>
>> *Exception Code : *
>> Exception: STATUS_ACCESS_VIOLATION at rip=00100401623
>> rax= rbx= rcx=000180201FC0
>> rdx=0006000284E0 rsi= rdi=0006000284D0
>> r8 = r9 =0020 r10=0001
>> r11=0001004015E0 r12=0002 r13=CC5E
>> r14=0003 r15=0001802193F0
>> rbp=CB30 rsp=CAB0
>> program=C:\x64\regtool.exe, pid 15244, thread main
>> cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> FrameFunctionArgs
>> 000CB30  00100401623 (00100020019, 049, 001801891FA,
>> 000CC5E)
>> 000CB9C  00100402704 (000, 000CC5E, 030,
>> FF0700010302FF00)
>> 000CCB0  00180047BC2 (000, 000, 000,
>> 000)
>> 000  00180045863 (000, 000, 000,
>> 000)
>> 000FFF0  00180045914 (000, 000, 000,
>> 000)
>> End of stack trace
>
> Unfortunately I can't reproduce this.  I tried both of your above
> example registry values, but in both cases I just get
>
>   Error (2): The system cannot find the file specified.
>
> As another test I created the above values in the registry, as
> REG_SZ with content == name and this works fine, too.
>
> Your stackdump indicates a crash in the function evaluating the
> command line argument, that is, "\HKCR\하하하" or "\HKCR\家".
>
> If so, I should see the same problem, unless the problem is a result of
> the locale you're using.  Can you please post the output of the `locale'
> command?
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

mksetupini fails validating packages because curr is test

[Ivan Gagis]

Hi,

I have an overlay cygwin repo where I publish my packages.

Recently I started getting errors from mksetupini script:

"
mksetupini: package 'mypackage' version '0.4.38-1' is most recent
non-test version, but version '0.4.43-1' is curr:
mksetupini: package set has errors, not writing setup.ini
"

there was no such errors before. And I don't have "test:" in any hint
files of my packages, so no I dea why it thinks that some versions are
non-test and curr is test?

Can you explain what this actually means?

Br,
Ivan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

mksetupini does not return error code

[Ivan Gagis]

Hi,

I found that in case packages validation fails the mksetup script just
returns success, though it prints a line in the console saying
"mksetupini: package set has errors, not writing setup.ini".

I think it should return some error code so that it would not be
considered as success by CI scripts where mksetupini is called from.

The problematic lines are as following:

https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/mksetupini.py;h=f24e4c5751e1f7e13516e8689c041403ba1f8d38;hb=HEAD#l63
returns nothing, should return non-zero error code.

https://cygwin.com/git/?p=cygwin-apps/calm.git;a=blob;f=calm/mksetupini.py;h=f24e4c5751e1f7e13516e8689c041403ba1f8d38;hb=HEAD#l118
returns nothing, should return result of do_main().

I'm not familiar with python, so I don't submit a patch, but even
without knowing python it is clearly seen that the errors are not
returned properly.

Br,
Ivan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Corinna Vinschen]

On Nov 29 13:36, Corinna Vinschen wrote:
> On Nov 29 13:04, Corinna Vinschen wrote:
> > - If you do async IO, you have to handle STATUS_PENDING gracefully:
> > 
> >   - The IO_STATUS_BLOCK given to NtWriteFile *must* exist for the
> > entire time the operation takes after NtWriteFile returned
> > STATUS_PENDING.  An IO_STATUS_BLOCK fhandler member comes to mind,
> > maybe fhandler_base_overlapped::io_status can be reused.
> 
> No, wait.  There can be more than one outstanding aio operations on the
> same descriptor.  Therefore the IO_STATUS_BLOCK must be connected to the
> aiocb struct one way or the other, becasue only that struct is local to
> the aio operation.

I guess that's what the Linux man page aio(7) subsumes under

  struct aiocb {
[...]

/* Various implementation-internal fields not shown */
  };


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Corinna Vinschen]

On Nov 29 13:04, Corinna Vinschen wrote:
> - If you do async IO, you have to handle STATUS_PENDING gracefully:
> 
>   - The IO_STATUS_BLOCK given to NtWriteFile *must* exist for the
> entire time the operation takes after NtWriteFile returned
> STATUS_PENDING.  An IO_STATUS_BLOCK fhandler member comes to mind,
> maybe fhandler_base_overlapped::io_status can be reused.

No, wait.  There can be more than one outstanding aio operations on the
same descriptor.  Therefore the IO_STATUS_BLOCK must be connected to the
aiocb struct one way or the other, becasue only that struct is local to
the aio operation.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Corinna Vinschen]

On Nov 29 03:27, Mark Geisert wrote:
> On Wed, 29 Nov 2017, I wrote:
> > I added the printf()s and, what do you know, it shows all the NtWriteFile()s
>  
> That's an American English idiom and is not meant to be taken literally.
> It's like "How about that?" or "Can you believe it?". Perhaps y'all know
> this idiom already but it was only while contemplating a cerveza that I
> realized it might have come across badly.

Nope, no worries.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Corinna Vinschen]

On Nov 29 02:25, Mark Geisert wrote:
> Corinna Vinschen wrote:
> > On Nov 28 02:28, Mark Geisert wrote:
> > > Corinna Vinschen wrote:
> > > > On Nov 28 00:03, Mark Geisert wrote:
> > > > > Oops, I neglected to include an explanatory comment. Issuing 
> > > > > simultaneous
> > > > > pwrite(s) on one file descriptor from multiple threads, as one might 
> > > > > do in a
> > > > > forthcoming POSIX aio implementation, sometimes results in garbage 
> > > > > status in
> > > > > the IO_STATUS_BLOCK on return from NtWriteFile(). Zeroing beforehand 
> > > > > made
> > > > > the issue go away.
> > > > > [...]
> > That doesn't mean it has been returned by NtWriteFile.  Random values
> > suggest NtWriteFile didn *set* a value in the first place, so what
> > you see is the random value from the stack position io is in.  And
> > that in turn suggests the status code should indicate why io wasn't
> > written by NtWriteFile.  If you're playing with async IO, is it possible
> > the status code indicates something like STATUS_TIMEOUT or STATUS_PENDING,
> > both of which are treated as NT_SUCCESS?
> > [...]
> I added the printf()s and, what do you know, it shows all the NtWriteFile()s
> are returning STATUS_PENDING.  On return some of the IO_STATUS_BLOCKS have the
> correct byte count but most of them have the same trash as before the call.

This is just a timing problem, see below.

> [...]
> Does this mean pwrite() should be waiting for the status to change from
> STATUS_PENDING to something else before returning?

MSDN has the following to say about this situation:

  The operating system implements support routines that write
  IO_STATUS_BLOCK values to caller-supplied output buffers. For example,
  see ZwOpenFile or NtOpenFile. These routines return status codes that
  might not match the status codes in the IO_STATUS_BLOCK structures. If
  one of these routines returns STATUS_PENDING, the caller should wait
  for the I/O operation to complete, and then check the status code in
  the IO_STATUS_BLOCK structure to determine the final status of the
  operation. If the routine returns a status code other than
  STATUS_PENDING, the caller should rely on this status code instead of
  the status code in the IO_STATUS_BLOCK structure.

STATUS_PENDING means the operation hasn't been finished yet, but that
only means that the IO_STATUS_BLOCK wasn't filled with correct information
when NtWriteFile returned.
^

So, after NtWriteFile returns with STATUS_PENDING it will still write
the completion status into the IO_STATUS_BLOCK parameter, as soon as it
finished its job, even if that takes a long time.

debug_printf of course takes time itself, so what happened in the
io.Infomation == 0x100 case was that NtWriteFile finished its job
while debug_printf was still collecting its wits.

The other NtWriteFile calls just didn't finish their job in time for
debug_printf to already get the completion status.

So what does that mean for us?

- If you don't do async IO on files, you're completely off the hook,
  because NtWriteFile will never return with STATUS_PENDING.

- If you do async IO, you have to handle STATUS_PENDING gracefully:

  - The IO_STATUS_BLOCK given to NtWriteFile *must* exist for the
entire time the operation takes after NtWriteFile returned
STATUS_PENDING.  An IO_STATUS_BLOCK fhandler member comes to mind,
maybe fhandler_base_overlapped::io_status can be reused.

  - You *must* call NtWriteFile with an event object as 2nd parameter,
which will be signalled when NtWriteFile completes (and then the
io.Status member indicates success or failure).  Otherwise you have
no chance to implement aio_error or any aio_sigevent method.

  - And of course, you don't wait in pwrite for completion.  That
would be counter to the idea of async I/O.  Rather, STATUS_PENDING
means returning -1 with errno set to EAGAIN.

On the other hand, aio_write would return 0 in this case, so calling
pwrite for the purpose of implementing aio_write shouldn't set
errno.  I guess changing pread/pwrite to return a negative error
value may be the better approach.  The caller would then turn this
into setting errno and a valid return value to user space.

I'd like to suggest the Freenode IRC channel #cygwin-developers for
discussion if something's unclear.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Mark Geisert]

On Wed, 29 Nov 2017, I wrote:

I added the printf()s and, what do you know, it shows all the NtWriteFile()s

 
That's an American English idiom and is not meant to be taken literally. 
It's like "How about that?" or "Can you believe it?". Perhaps y'all know 
this idiom already but it was only while contemplating a cerveza that I 
realized it might have come across badly.

Cheers & Regards,

..mark

Re: [PATCH] Initialize IO_STATUS_BLOCK for pread, pwrite

[Mark Geisert]

Corinna Vinschen wrote:

On Nov 28 02:28, Mark Geisert wrote:

Corinna Vinschen wrote:

On Nov 28 00:03, Mark Geisert wrote:

Mark Geisert wrote:

---
 winsup/cygwin/fhandler_disk_file.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 5dfcae4d9..2ead9948c 100644

[...]

Oops, I neglected to include an explanatory comment. Issuing simultaneous
pwrite(s) on one file descriptor from multiple threads, as one might do in a
forthcoming POSIX aio implementation, sometimes results in garbage status in
the IO_STATUS_BLOCK on return from NtWriteFile(). Zeroing beforehand made
the issue go away.

This is mildly concerning to me because there are many other uses of
IO_STATUS_BLOCK in the Cygwin DLL that haven't seemed to have needed
initialization.

Puzzledly,


Ok, let's start with, why did you tweak pread if you only observed
a problem in pwrite?


Optimism? :-)  No, you're correct; I was getting ahead of myself.


  In terms of pread, we already have a very recent
patch series:

https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=46702f92ea49
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=c983aa48798d
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=181fe5d2edac

In this case it turned out that the problem was related to hitting EOF.
I wonder if we hit a similar problem here.

Two points:

- Did you check the status code returned by NtWriteFile?  Not all non-0
  status codes fail the !NT_SUCCESS (status) test.


I did check the status code but don't recall what it was.  The symptom I was
seeing was outlandish io.Information values being returned by pwrite().  Far
larger than the number requested in the call to pwrite() and NtWriteFile().


That doesn't mean it has been returned by NtWriteFile.  Random values
suggest NtWriteFile didn *set* a value in the first place, so what
you see is the random value from the stack position io is in.  And
that in turn suggests the status code should indicate why io wasn't
written by NtWriteFile.  If you're playing with async IO, is it possible
the status code indicates something like STATUS_TIMEOUT or STATUS_PENDING,
both of which are treated as NT_SUCCESS?


- Do you have a simple, self-contained testcase?


That would be difficult.  I can supply an strace excerpt just showing the
region of these simultaneous pwrite() calls, without this patch.  If it's
too large I'll put it somewhere and post a link (but I don't think it will
be).


Alternatively, what you should do is adding debug_printf statements
before and after NtWriteFile, kind of like this...


I added the printf()s and, what do you know, it shows all the NtWriteFile()s
are returning STATUS_PENDING.  On return some of the IO_STATUS_BLOCKS have the
correct byte count but most of them have the same trash as before the call.

This is 8 threads each pwriting a 16MB chunk to different addresses in a new
128MB file.  4 threads pwriting 32MB chunks showed correct pwrite() results.

Does this mean pwrite() should be waiting for the status to change from
STATUS_PENDING to something else before returning?

..mark

18221 1193697 [aio6] heapxfer 3024 fhandler_disk_file::prw_open: 0x0 = NtOpenFile (0x1C4, 0x1B6, 
\??\C:\cygwin64\tmp\heapfile, io, 0x7, 0x0)

   53 1193750 [aio6] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x3033207265667870
   60 1193810 [aio3] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x5D336F69615B2038
   68 1193878 [aio2] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x5D326F69615B2033
   70 1193948 [aio8] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x3033207265667870
   40 1193988 [aio5] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x3033207265667870
   33 1194021 [aio4] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x3033207265667870
   29 1194050 [aio1] heapxfer 3024 fhandler_disk_file::pwrite: Before NtWF, io 
0x5D316F69615B2036
 5652 1199702 [aio6] heapxfer 3024 fhandler_disk_file::pwrite: After NtWF, io 
0x100, status 0x103
   74 1199776 [aio6] heapxfer 3024 pwrite: 16777216 = pwrite(3, 0x6FFF7FF, 
16777216, 0)
   29 1199805 [aio6] heapxfer 3024 getpid: 3024 = getpid()
   24 1199829 [aio6] heapxfer 3024 sig_send: sendsig 0x80, pid 3024, signal 23, 
its_me 1
   32 1199861 [aio6] heapxfer 3024 sig_send: wakeup 0x1C8
   30 1199891 [aio6] heapxfer 3024 sig_send: Waiting for pack.wakeup 0x1C8
  239 1200130 [aio2] heapxfer 3024 fhandler_disk_file::pwrite: After NtWF, io 
0x5D326F69615B2033, status 0x103
  307 1200437 [aio2] heapxfer 3024 pwrite: 1633361971 = pwrite(3, 
0x6FFFAFF, 16777216, 50331648)
  179 1200616 [sig] heapxfer 3024 sigpacket::process: signal 23 processing
   27 1200643 [aio5] heapxfer 3024 fhandler_disk_file::pwrite: After NtWF, io 
0x3033207265667870, status 0x103
   26 1200669 [aio5] heapxfer 3024 pwrite: 1701214320 = pwrite(3, 

Re: Cygwin 2.9.0 regtool x64 exception error (W10)

[Corinna Vinschen]

Hi ViOLeT,

On Nov 29 15:33, ViOLeT wrote:
> Hello.
> 
> Cygwin 2.9.0 regtool x64 exception error (W10) reporting. (But it seems to
> be an error in all (2.9.0 lower) versions.)
> 
> Using the Unicode causes an exception error.
> But, regtool x86 is no error occurs.
> 
> *Example :*
> regtool.exe -w get "\HKCR\하하하"
> regtool.exe -w get "\HKCR\家"
> 
> *Exception Code : *
> Exception: STATUS_ACCESS_VIOLATION at rip=00100401623
> rax= rbx= rcx=000180201FC0
> rdx=0006000284E0 rsi= rdi=0006000284D0
> r8 = r9 =0020 r10=0001
> r11=0001004015E0 r12=0002 r13=CC5E
> r14=0003 r15=0001802193F0
> rbp=CB30 rsp=CAB0
> program=C:\x64\regtool.exe, pid 15244, thread main
> cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
> Stack trace:
> FrameFunctionArgs
> 000CB30  00100401623 (00100020019, 049, 001801891FA,
> 000CC5E)
> 000CB9C  00100402704 (000, 000CC5E, 030,
> FF0700010302FF00)
> 000CCB0  00180047BC2 (000, 000, 000,
> 000)
> 000  00180045863 (000, 000, 000,
> 000)
> 000FFF0  00180045914 (000, 000, 000,
> 000)
> End of stack trace

Unfortunately I can't reproduce this.  I tried both of your above
example registry values, but in both cases I just get

  Error (2): The system cannot find the file specified.

As another test I created the above values in the registry, as
REG_SZ with content == name and this works fine, too.

Your stackdump indicates a crash in the function evaluating the
command line argument, that is, "\HKCR\하하하" or "\HKCR\家".

If so, I should see the same problem, unless the problem is a result of
the locale you're using.  Can you please post the output of the `locale'
command?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature