Problem with exception handling on alt stacks

Hi all, I recently ran into a tricky problem when working with cysignals [1] on Cygwin: Cysignals provides signal handlers for code written in C or Cython running in a Python interpreter, which converts otherwise unhandled signals into Python exceptions. It recently started using sigaltstack

Introducing PyCygwin

Hi folks, Just a little spam for a project I put together that might be of interest to some people in the Cygwin community. Python bindings for Cygwin's C API [1]: https://github.com/embray/PyCygwin The first release (0.1) is pretty threadbare and does not support most of the API yet, but I

Re: OpenBLAS patch for Cygwin

On Tue, Feb 6, 2018 at 7:07 PM, Achim Gratz wrote: > Erik Bray writes: >> Assuming this looks good (feedback welcome) it might be nice to have >> this patch included in the next release of the official OpenBLAS >> package for Cygwin since its incompatibility with fork() h

Re: OpenBLAS patch for Cygwin

Hi, Sorry for the non-response. Been traveling for the last week and not really checking this e-mail much. On Tue, Feb 6, 2018 at 3:15 PM, Marco Atzeri wrote: > On 06/02/2018 13:10, Erik Bray wrote: >> >> Hello, >> >> Users/maintainers of OpenBLAS on Cygwin may be

OpenBLAS patch for Cygwin

Hello, Users/maintainers of OpenBLAS on Cygwin may be interested in this patch to improve support for fork(): https://github.com/xianyi/OpenBLAS/pull/1450 Assuming this looks good (feedback welcome) it might be nice to have this patch included in the next release of the official OpenBLAS package

Windows Defender Exploit Guard

Hi all, I've seen some reports, and encountered some problems myself, with the new "Windows Defender Exploit Guard" [1] w.r.t. Cygwin. This enables a number of anti-exploit protections, at least some of which might be a problem for Cygwin--in particular "Force randomization for images (Mandatory

Re: [PATCH] Fix two bugs in the limit of large numbers of sockets:

On Nov 7, 2017 16:36, "Corinna Vinschen" wrote: Erik, On Nov 7 16:11, Corinna Vinschen wrote: > On Nov 7 14:44, Erik M. Bray wrote: > > * Fix the maximum number of sockets allowed in the session to 2048, > > instead of making it relative to sizeof(wsa_event). > > > > The original choice of

Bug in poll/select readable state on write end of pipe

Hi, I encountered this bug through a hang in Twisted, but narrowed it down to a simple example (in Python here, but the same would work in C). Basically, in Twisted's system process runner, there's a "hack" [1] which basically assumes readability (as in a poll() loop) of the writable end of a

Re: Bug(s) with creating large numbers of sockets

On Nov 3, 2017 9:36 PM, "Corinna Vinschen" wrote: Hi Erik, why didn't you send this to cygwin-patches? Not much of a problem, just wondering... Will follow up more later, but just to clarify on this a bit I thought the issue was just interesting, and that the question(s) of the upper limit

Re: Problem running the latest python2-2.7.14-1 under AppVeyor

On Fri, Nov 3, 2017 at 3:45 PM, Vadim Zeitlin wrote: > Hello, > > Our build has started on AppVeyor, a continuous integration provider, > started failing since a couple of days as a makefile command running a > Python script started failing with exit code 127 without any more > information. This

Bug(s) with creating large numbers of sockets

Hi all, I found a few bugs in Cygwin w.r.t. creating large numbers of sockets. For example, Cygwin will gladly let you create up to RLIMIT_NOFILE sockets (examples in Python, where I found this problem): >>> import resource >>> import socket >>> resource.getrlimit(resource.RLIMIT_NOFILE) (256,

Re: [PATCH 1/2] posix_fadvise() *returns* error codes but does not set errno

On Thu, Nov 2, 2017 at 6:10 PM, Corinna Vinschen wrote: > On Nov 2 16:45, Erik M. Bray wrote: >> Also updates the fhandler_*::fadvise implementations to adhere to the same >> semantics. > > Both patches pushed. Thanks!

Re: [PATCH 2/2] posix_fallocate() *returns* error codes but does not set errno

On Thu, Nov 2, 2017 at 4:06 PM, Corinna Vinschen wrote: > Hi Erik, > > On Nov 2 15:15, Erik M. Bray wrote: >> diff --git a/winsup/cygwin/fhandler_disk_file.cc >> b/winsup/cygwin/fhandler_disk_file.cc >> index f46e355..9d5ec30 100644 >> --- a/winsup/cygwin/fhandler_disk_file.cc >> +++

Re: [PATCH] posix_fadvise() *returns* error codes but does not set errno

On Thu, Nov 2, 2017 at 3:58 PM, Corinna Vinschen wrote: > Hi Eric, > > On Nov 2 14:26, Erik M. Bray wrote: >> Also updates the fhandler_*::fadvise implementations to adhere to the same >> semantics. > > Good catch. I have just some style nits. > >> --- >>

Re: Cygwin on Win10 much slower than Win7

On Wed, Nov 1, 2017 at 3:50 PM, Nellis, Kenneth wrote: > Since migrating from a Windows 7 laptop to one with Windows > 10, I've noticed a significant speed decrease in opening a > mintty/bash window from about 0.5s to 3.5s. > > I've narrowed it down to two bottlenecks in .bash_profile: > to

Re: Strange bug with /dev/console in mintty

On Wed, Aug 23, 2017 at 6:08 PM, Corinna Vinschen wrote: > On Aug 23 10:33, Corinna Vinschen wrote: >> On Aug 22 18:49, Erik Bray wrote: >> > Hi folks, >> > >> > I noticed a strange discrepancy when running Cygwin through mintty, vs >> > through a nor

Strange bug with /dev/console in mintty

Hi folks, I noticed a strange discrepancy when running Cygwin through mintty, vs through a normal cmd.exe console. This is on a build from the latest git master, but also on Cygwin 2.8.0. When run from a cmd.exe console, we can see the following output from fhandler_dev::readdir: $ ls -l

Re: rebase segmentation fault

On Mon, Jul 17, 2017 at 11:05 AM, Corinna Vinschen wrote: > On Jul 17 10:35, Corinna Vinschen wrote: >> On Jul 16 19:16, Denis Excoffier wrote: >> > Hello, >> > >> > I have a Cygwin installation under Windows 7 (32 bits). >> > >> > After 'rebase-trigger full' and 'Setup', autorebase seems to

Re: Bug? wcsxfrm causing memory corruption

On Tue, Jun 6, 2017 at 9:22 PM, Corinna Vinschen wrote: > On Jun 6 17:57, Corinna Vinschen wrote: >> > > On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote: >> > >> [...] >> > >> The attached test demonstrates the bug. Given an output

Re: [PATCH] Ensure that a blocking send() on a socket returns (with success) if a signal is handled mid-transition and SA_RESTART is not set.

On Tue, Jun 6, 2017 at 4:23 PM, Corinna Vinschen wrote: > Hi Erik, > > [vacation-induced late reply] No problem--you had been silent here for a while so I guessed you were on vacation. Welcome back! > On May 11 16:05, Erik M. Bray wrote: >> --- >>

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, May 24, 2017 at 6:57 PM, Eric Blake wrote: > On 05/24/2017 11:53 AM, Erik Bray wrote: > >>>> dropping down to assembly; it could very well be that the assembly code >>>> is incorrectly truncating things at 32 bits (where it is just fine for >>&g

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, May 24, 2017 at 5:55 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote: >> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: >>> I am experiencing problems printing long int values under cygwin64 >>>

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote: > On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: >> I am experiencing problems printing long int values under cygwin64 installed >> on a Windows 10 machine. >> >> Below is a test program followed by its output to demonstrate the problem.

Re: Python2 "narrow" build, Unicode issue in regex package

On Wed, May 24, 2017 at 10:30 AM, Václav Haisman wrote: > Hi. > > I have recently hit an issue ([1]) with Python 2.7 and regex package > for it on Cygwin. It appears that Cygwin's Python 2.7 is so called > narrow build. This causes issues when working with Unicode code point > outside BMP, like

Re: Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

On Wed, May 24, 2017 at 9:52 AM, Ronald Fischer wrote: > I have a file X which contains ASCII text, but also in some lines German > umlaut characters. The file is classified as: > > $ file X > X: ISO-8859 text, with CRLF line terminators > > If I grep the file using, say, > > $ grep

Re: Bug? wcsxfrm causing memory corruption

On Sun, May 21, 2017 at 6:23 AM, Duncan Roe wrote: > On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote: >> Greetings-- >> >> In the process of fixing the Python test suite on Cygwin I ran across >> one test that was consistently causing segfaults late

Bug? wcsxfrm causing memory corruption

Greetings-- In the process of fixing the Python test suite on Cygwin I ran across one test that was consistently causing segfaults later on, not directly local to that test. The test involves wcsxfrm so that's where I focused my attention. The attached test demonstrates the bug. Given an

Re: [ANNOUNCEMENT] Updated: lapack-3.7.0-1

On Wed, Jan 11, 2017 at 9:41 AM, Marco Atzeri wrote: > To: cygwin-annou...@cygwin.com > Subject: Updated: lapack-3.7.0-1 > > New versions lapack-3.7.0-1 of > > lapack (source) > liblapack0 > liblapack-devel > liblapack-doc > > are available in the Cygwin distribution, 32 and 64 bit : > > CHANGES

Re: Numpy 1.12.1 setup issue (targetting Python 3.6.1) from Cygwin 2.8.0

On Mon, Apr 17, 2017 at 12:01 PM, Kptain wrote: > I have installed python-dev package on Cygwin. > > It seems to be better as now I am able to build wheels for collected > packages: numpy > > $ pip3 install numpy > Collecting numpy > Using cached numpy-1.12.1.zip >

Re: fork() fails if it is called recursively from a child thread.

On Sat, Mar 11, 2017 at 2:29 AM, Takashi Yano wrote: > Hello, > > On Fri, 10 Mar 2017 21:10:36 +0100 Corinna Vinschen wrote: >> Thanks for the report and especially the testcase. >> >> It was a tricky problem to debug so it took me a while, but I think >> I got it now. >> >> I uploaded new

Re: Problem with zombie processes

On Mon, Feb 20, 2017 at 11:54 PM, Mark Geisert wrote: > Erik Bray wrote: >> >> On Mon, Feb 20, 2017 at 11:54 AM, Mark Geisert wrote: >>>> >>>> So my guess was that Cygwin might try to hold on to a handle to a >>>> child process at least until

Re: Problem with zombie processes

On Mon, Feb 20, 2017 at 11:54 AM, Mark Geisert wrote: >> So my guess was that Cygwin might try to hold on to a handle to a >> child process at least until it's been explicitly wait()ed. But that >> does not seem to be the case after all. > > > You might have missed a subtlety in what I said

Re: Problem with zombie processes

On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <m...@maxrnd.com> wrote: > Erik Bray wrote: >> >> On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert <x...@xx.xxx> wrote: > > > Please don't quote raw email addresses. We try to avoid feeding spammers. Sorry--norma

Re: Problem with zombie processes

On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert <m...@maxrnd.com> wrote: > Erik Bray wrote: >> >> The attached Python script > > > ?? D'oh! Here is the script. It at least demonstrates the problem. test.py Description: Binary data -- Problem reports: http:

Problem with zombie processes

Hi all, I encountered a strange bug concerning zombie child processes during my testing. Specifically, it came up in the context of trying to read the /proc/ entries of processes that should be zombified but not reaped yet (i.e. they have received and processed a SIGKILL or SIGTERM but have not

Re: Problems with ssh-host-config on Windows 10

On Thu, Feb 2, 2017 at 2:08 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Feb 2 12:19, Erik Bray wrote: >> Hi all, >> >> I've been trying to get a Cygwin sshd server running on a Windows 10 >> VM, and have found it to be surprisingly tricky wi

Problems with ssh-host-config on Windows 10

Hi all, I've been trying to get a Cygwin sshd server running on a Windows 10 VM, and have found it to be surprisingly tricky without some additional fiddling, and it's not clear to me whether that's expected or if it's a bug. I've attached the cygcheck output from the VM. The symptom I've

Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

On Mon, Jan 9, 2017 at 6:16 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Jan 9 16:46, Erik Bray wrote: >> Hi Corinna, >> >> Thanks for the response. >> >> On Mon, Jan 9, 2017 at 3:13 PM, Corinna Vinschen wrote: >> > Right. It has

Re: [PATCH 0/3] Updated patches for /proc//environ

On Tue, Jan 10, 2017 at 4:41 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Jan 10 16:02, Erik Bray wrote: >> From: "Erik M. Bray" <erik.b...@lri.fr> >> >> Updated versions of the patch set originally submitted at >> https://cygwin.co

[PATCH 2/3] Add a _pinfo.environ() method analogous to _pinfo.cmdline(), and others.

From: Erik M. Bray Returns the process's environment concatenated into a single block of null-terminated strings, along with the length of the environment block. Adds an associated PICOM_ENVIRON commune_process handler. --- winsup/cygwin/pinfo.cc | 83

[PATCH 3/3] Add a /proc//environ proc file handler, analogous to /proc//cmdline.

From: Erik M. Bray --- winsup/cygwin/fhandler_process.cc | 22 ++ 1 file changed, 22 insertions(+) diff --git a/winsup/cygwin/fhandler_process.cc b/winsup/cygwin/fhandler_process.cc index 5f530a2..bbb44fa 100644 --- a/winsup/cygwin/fhandler_process.cc +++

[PATCH 1/3] Move the core environment parsing of environ_init into a new win32env_to_cygenv function.

From: Erik M. Bray win32env_to_cygwenv handles converting wchar to char and some other minor taks. Optionally it handles converting any paths in variables to posix paths. This will be useful for implementing /proc//environ --- winsup/cygwin/environ.cc | 84

Re: [PATCH 2/3] Add a _pinfo.environ() method analogous to _pinfo.cmdline(), and others.

On Mon, Jan 9, 2017 at 3:58 PM, Corinna Vinschen wrote: > On Jan 5 18:39, Erik M. Bray wrote: >> diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc >> index 1ce6809..a3e376c 100644 >> --- a/winsup/cygwin/pinfo.cc >> +++ b/winsup/cygwin/pinfo.cc >> @@ -653,8

Re: [PATCH 0/3] Add support for /proc//environ

On Mon, Jan 9, 2017 at 3:43 PM, Corinna Vinschen wrote: > Hi Erik, > > On Jan 5 18:39, erik.m.b...@gmail.com wrote: >> From: "Erik M. Bray" >> >> Per this discussion started in this thread: >> https://cygwin.com/ml/cygwin/2016-11/msg00205.html >> >>

Re: [PATCH] Return the correct value for getsockopt(SO_REUSEADDR) after setting setsockopt(SO_REUSEADDR, 1).

On Mon, Jan 9, 2017 at 5:58 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Jan 9 17:36, Erik Bray wrote: >> --- >> winsup/cygwin/net.cc | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/

[PATCH] Return the correct value for getsockopt(SO_REUSEADDR) after setting setsockopt(SO_REUSEADDR, 1).

From: Erik M. Bray --- winsup/cygwin/net.cc | 8 1 file changed, 8 insertions(+) diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc index e4805d3..b02f9e3 100644 --- a/winsup/cygwin/net.cc +++ b/winsup/cygwin/net.cc @@ -925,6 +925,14 @@ cygwin_getsockopt (int

Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

Hi Corinna, Thanks for the response. On Mon, Jan 9, 2017 at 3:13 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > Hi Erik, > > On Jan 9 14:29, Erik Bray wrote: >> On Mon, Jan 9, 2017 at 12:01 PM, Erik Bray <erik.m.b...@gmail.com> wrote: >> > On Fri

Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

On Mon, Jan 9, 2017 at 12:01 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > On Fri, Jan 6, 2017 at 12:40 PM, Erik Bray <erik.m.b...@gmail.com> wrote: >> Hello, and happy new-ish year, >> >> I've been working on and off over the past few months on bringing >>

Re: Cygwin hanging in pselect

On Fri, Jan 6, 2017 at 12:40 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > Hello, and happy new-ish year, > > I've been working on and off over the past few months on bringing > Python's compatibility with Cygwin up to snuff, including having all > pertinent tests p

Cygwin hanging in pselect

Hello, and happy new-ish year, I've been working on and off over the past few months on bringing Python's compatibility with Cygwin up to snuff, including having all pertinent tests passing. I've noticed that there are several tests (which I currently skip) that cause the process to hang

Re: compile python executable file on cygwin for windows

n1.dll > cygcheck can also find it . You need to make sure that cygwin1.dll and any other required DLLs are bundled with your application, preferably in the same directory, or else it won't be able to find them. There's a good tutorial here: https://www.youtube.com/watch?v=abM_ysmpenc > On

Re: compile python executable file on cygwin for windows

On Mon, Dec 19, 2016 at 4:07 PM, Goodman Leung wrote: > hi all > > i install python and pyinstaller on cygwin , and i can run pyinstaller > successfully to compile a exe file on the cygwin environment . > > but when i launch this executable file on window with double click

Re: Retrieving per-process environment block?

On Wed, Nov 30, 2016 at 11:43 AM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > Hi Erik, > > On Nov 29 14:26, Erik Bray wrote: >> On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen >> <corinna-cyg...@cygwin.com> wrote: >> > On N

Re: Retrieving per-process environment block?

On Wed, Nov 30, 2016 at 10:15 AM, Peter Rosin wrote: > On 2016-11-30 04:00, Eliot Moss wrote: >> On 11/29/2016 7:28 PM, Herbert Stocker wrote: >> >>> Or we simply copy the variables unconverted to the Windows environment >>> block, as the Windows env block is not used for

Re: Retrieving per-process environment block?

On Tue, Nov 29, 2016 at 3:28 PM, Eliot Moss <m...@cs.umass.edu> wrote: > On 11/29/2016 8:26 AM, Erik Bray wrote: >> >> On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen >> <corinna-cyg...@cygwin.com> wrote: >>> >>> On Nov 17 14:30, Erik Bray

Re: Retrieving per-process environment block?

On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Nov 17 14:30, Erik Bray wrote: >> Hi all, >> >> For a quick bit of background, I'm working on porting the highly >> useful psutil [1] Python library to Cygwin. This has

Re: python 2.7.12 pip install with extensions fails with warning: "__BSD_VISIBLE" redefined

On Wed, Nov 23, 2016 at 4:24 AM, Jason Bell wrote: > Hi - > > The newest version of cygwin with python 2.7.12-1 fails when pip > installing packages that require compilation. For example, pycrypto > fails: > > $ pip install pycrypto > Collecting pycrypto > ... >

Retrieving per-process environment block?

Hi all, For a quick bit of background, I'm working on porting the highly useful psutil [1] Python library to Cygwin. This has proved an interesting exercise, as much of the functionality of psutil works on Cygwin through existing POSIX interfaces, and a handful of Linux-specific interfaces as

Re: Return the correct value for sysconf(_SC_PAGESIZE)

On Thu, Nov 17, 2016 at 10:54 AM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Nov 16 15:51, Erik Bray wrote: >> On Wed, Nov 16, 2016 at 3:01 PM, Eric Blake <ebl...@redhat.com> wrote: >> > On 11/16/2016 07:56 AM, Erik Bray wrote: >> > >&g

Re: Return the correct value for sysconf(_SC_PAGESIZE)

On Wed, Nov 16, 2016 at 3:01 PM, Eric Blake <ebl...@redhat.com> wrote: > On 11/16/2016 07:56 AM, Erik Bray wrote: > >>> There is no good reason to use the non-POSIXy page size. It doesn't >>> help you in the least for any pagesize-related functionality. Mmap >

Re: Return the correct value for sysconf(_SC_PAGESIZE)

On Tue, Nov 15, 2016 at 5:19 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Nov 15 16:47, Erik Bray wrote: >> On Tue, Nov 15, 2016 at 3:58 PM, Corinna Vinschen >> <corinna-cyg...@cygwin.com> wrote: >> > On Nov 15 14:51, Erik Bray wrote: >> &

Re: Return the correct value for sysconf(_SC_PAGESIZE)

On Tue, Nov 15, 2016 at 3:58 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > On Nov 15 14:51, Erik Bray wrote: >> Greetings, >> >> Currently sysconf(_SC_PAGESIZE) returns the value of >> wincap.allocation_granularity()--a change I *think* had to have be

Return the correct value for sysconf(_SC_PAGESIZE)

Greetings, Currently sysconf(_SC_PAGESIZE) returns the value of wincap.allocation_granularity()--a change I *think* had to have been made by mistake in https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;f=winsup/cygwin/sysconf.cc;h=177dc6c7f6d0608ef6540fd997d9b444e324cae2 There's no

Re: 2.5.1: kill(pid, sig) before waitpid() returns -1 for sig != 0

On Thu, Aug 11, 2016 at 4:13 PM, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > Hi Eric, > > On Aug 11 11:51, Erik Bray wrote: >> [...] >> > Existing implementations vary on the result of a kill() with pid >> > indicating an inactive process (a &g

2.5.1: kill(pid, sig) before waitpid() returns -1 for sig != 0

Hi all, This is a followup to a report back in 2011 about essentially the same issue: https://cygwin.com/ml/cygwin/2011-04/msg00031.html The same test program in that report demonstrates the issue, but with kill sending any non-zero signal. To reiterate, the problem here is POSIX compliance

Segfault in MAP_NORESERVE mmap above ~4GB

Hi all, This issue pertains to Cygwin 64-bit. The following example program demonstrates the issue: $ cat mmap_test.c #include #include #include #define VSIZE 0x11000 #define SIZE 0x1000 void foo() { void *top, *bot, *c; c = mmap(NULL, VSIZE, PROT_READ|PROT_WRITE,