thing...
Thoughts welcome!
Thank you!
/haubi/
From 7bcae68c5b8c3b55e9abeafcd7493e2c50243474 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com
Date: Tue, 21 Jul 2015 16:15:05 +0200
Subject: [PATCH] Protect fork() against dll- and exe-updates.
To support
To avoid the need for each process to check the filesystem to detect
that hardlink creation is impossible or disabled, cache this fact in
shared memory. Removing cygfork directory while in use does disable
hardlinks creation. To (re-)enable hardlinks creation, the cygfork
directory has to exist
On 03/30/2016 09:04 PM, Yaakov Selkowitz wrote:
> On 2016-03-30 13:53, Michael Haubenwallner wrote:
>> To support in-cygwin package managers, the fork() implementation must
>> not rely on .exe and .dll files to stay in their original location, as
>> the package manage
In preparation to protect fork() against dll- and exe-updates, create
hardlinks to the main executable and each loaded dll in subdirectories
of /var/run/cygfork/, if that one exists on the NTFS file system.
The directory names consist of the user sid, the main executable's NTFS
IndexNumber, and
Hi,
this is the updated and split series of patches to use hardlinks
for creating the child process by fork(), in reply to
https://cygwin.com/ml/cygwin-developers/2016-01/msg2.html
https://cygwin.com/ml/cygwin-developers/2016-03/msg5.html
http://thread.gmane.org/gmane.os.cygwin.devel/1378
To support in-cygwin package managers, the fork() implementation must
not rely on .exe and .dll files to stay in their original location, as
the package manager's job is to replace these files. Instead, we use
the hardlinks to the original binaries in /var/run/cygfork/ to create
the child process
In preparation to protect fork() against dll- and exe-updates, store
any dll file name as full NT path. Additionally, keep a file handle
open for each loaded dll file for subsequent hardlink creation. The
earlier we open a handle to the dll file, the lower is the chance the
dll file has been
In preparation to protect fork() against dll- and exe-updates, even for
the main executable and cygwin1.dll store the file name as full NT path,
and keep handles to the files open for subsequent hardlink creation.
Create the child process using the main executable's file name converted
from the
On 03/30/2016 08:55 PM, Daniel Colascione wrote:
>
>
> On 03/30/2016 11:53 AM, Michael Haubenwallner wrote:
>> Hi,
>>
>> this is the updated and split series of patches to use hardlinks
>> for creating the child process by fork(), in reply to
>> https://
0.html
here's the patch, intended as fixup for
>
> [PATCH 3/6] forkables: Create forkable hardlinks, yet unused.
> https://cygwin.com/ml/cygwin-developers/2016-12/msg6.html
Thanks!
/haubi/
>From 66bc7176ad9a786651c306e27ce354438db5d4af Mon Sep 17 00:00:00 2001
From: Michael Hau
Creating both version.cc and winver.o at once really should run once only.
---
winsup/cygwin/Makefile.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index bffb24a..c8652b0 100644
--- a/winsup/cygwin/Makefile.in
+++
On 08/31/2016 09:12 PM, Corinna Vinschen wrote:
> Hi Michael,
>
> On Aug 31 20:07, Michael Haubenwallner wrote:
>> Instead of find_exec, without changing behaviour use new pathfinder
>> class with new allocator_interface around tmp_pathbuf and new vstrlist
>> class.
&g
On 09/01/2016 04:03 PM, Corinna Vinschen wrote:
> On Sep 1 13:05, Michael Haubenwallner wrote:
>> On 08/31/2016 09:12 PM, Corinna Vinschen wrote:
>>> On Aug 31 20:07, Michael Haubenwallner wrote:
>>>> Instead of find_exec, without changing behaviour use new
Hi Corinna,
On 09/01/2016 03:32 PM, Corinna Vinschen wrote:
> On Aug 31 20:07, Michael Haubenwallner wrote:
>> citing https://cygwin.com/ml/cygwin-developers/2016-08/msg00020.html
>>> Consider the file /usr/bin/cygz.dll:
>>> - dlopen (libz.so)success
>
On 09/02/2016 10:52 AM, Corinna Vinschen wrote:
> On Sep 2 10:05, Michael Haubenwallner wrote:
>> On 09/01/2016 04:03 PM, Corinna Vinschen wrote:
>>> On Sep 1 13:05, Michael Haubenwallner wrote:
>>>> On 08/31/2016 09:12 PM, Corinna Vinschen wrote:
>>>&g
On 09/02/2016 11:03 AM, Corinna Vinschen wrote:
> On Sep 2 10:46, Michael Haubenwallner wrote:
>> On 09/01/2016 03:32 PM, Corinna Vinschen wrote:
>>> You could just use the global variable program_invocation_name. If in
>>> doubt, use the Windows path global_progname a
Hi Corinna,
On 09/01/2016 04:05 PM, Corinna Vinschen wrote:
> On Aug 31 20:07, Michael Haubenwallner wrote:
>> Applications installed to some prefix like /opt/application do expect
>> dlopen("libAPP.so") to load "/opt/application/bin/cygAPP.dll", which
>
Applications installed to some prefix like /opt/application do expect
dlopen("libAPP.so") to load "/opt/application/bin/cygAPP.dll", which
is similar to "/opt/application/lib/libAPP.so" on Linux.
See also https://cygwin.com/ml/cygwin-developers/2016-08/msg00020.html
* dlfcn.cc (dlopen): For
Rather than searching all search dirs per one basename,
search for all basenames within per one search dir.
pathfinder.h (check_path_access): Interchange dir- and basename-loops.
---
winsup/cygwin/pathfinder.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Hi Corinna,
based on the discussion on -developers list [1][2], here's a reworked
set of patches for dlopen, split along these features and fixes.
[1] https://cygwin.com/ml/cygwin-developers/2016-06/msg0.html
[2] https://cygwin.com/ml/cygwin-developers/2016-08/msg0.html
*) Switch to
On 09/08/2016 01:58 PM, Corinna Vinschen wrote:
> On Sep 2 13:36, Michael Haubenwallner wrote:
>> On 09/02/2016 10:52 AM, Corinna Vinschen wrote:
>>> On Sep 2 10:05, Michael Haubenwallner wrote:
>>>> Moving the allocator into pathfinder would work then, but still
On 03/30/2016 08:53 PM, Michael Haubenwallner wrote:
> In preparation to protect fork() against dll- and exe-updates, create
> hardlinks to the main executable and each loaded dll in subdirectories
> of /var/run/cygfork/, if that one exists on the NTFS file system.
>
> The director
(sorry about previous empty mail)
Hi Corinna,
This is a fixup for the race condition where multiple processes failed
to concurrently create identical hardlinks.
So I'm quite successful with the forkable hardlinks now...
/haubi/
On 03/30/2016 08:53 PM, Michael Haubenwallner wrote
When the current process has renamed (to bin) a readonly dll, we get
STATUS_TRANSACTION_NOT_ACTIVE for unknown reason when subsequently
creating the forkable hardlink. A workaround is to open the original
file with FILE_WRITE_ATTRIBUTES access, but that fails with permission
denied for users not
And LONG fits better for shared_info member forkable_hardlink_support.
---
winsup/cygwin/dll_init.cc | 1 +
winsup/cygwin/dll_init.h| 6 --
winsup/cygwin/fork.cc | 1 +
winsup/cygwin/forkable.cc | 8 +---
winsup/cygwin/shared_info.h | 4 ++--
5 files changed, 9
ced "enum forkables_needs" with
"bool forkables_created", because the "needless" value now is
implemented as "first fork tries without hardlinks". So as soon as
request_forkables() is entered, hardlinks aren't "needless" any more.
> That's all.
With "%C" format string, argument may convert in up to MB_LEN_MAX bytes.
Relying on sys_wcstombs to add a trailing zero here requires us to
provide a large enough buffer.
* smallprint.c (__small_vsprintf): Use MB_LEN_MAX+1 bufsize for "%C".
---
winsup/cygwin/smallprint.cc | 4 ++--
1 file
When fork fails, we can use "%s" now with system_sprintf for the errmsg
rather than a (potentially too small) buffer for the format string.
* fork.cc (fork): Use "%s" with system_printf now.
---
winsup/cygwin/fork.cc | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
On 10/10/2017 02:44 PM, Corinna Vinschen wrote:
> On Oct 10 14:26, Michael Haubenwallner wrote:
>> On 10/10/2017 01:48 PM, Corinna Vinschen wrote:
>>> Hi Michael,
>>>
>>> On Oct 9 18:58, Michael Haubenwallner wrote:
>>>> When fork fails, we can
On 10/10/2017 01:48 PM, Corinna Vinschen wrote:
> Hi Michael,
>
> On Oct 9 18:58, Michael Haubenwallner wrote:
>> When fork fails, we can use "%s" now with system_sprintf for the errmsg
>> rather than a (potentially too small) buffer for the format string.
>
.
The command in question (with longer PATH environment variable) was:
$ x86_64-pc-cygwin-nm -f posix -A /lib/libcygwin.a | sed 1q
It was important to locate nm via PATH, not with /path/to/nm.
Thanks!
/haubi/
>From b029e683e2a03879c3c1cee06bf6cd2af86b67d9 Mon Sep 17 00:00:00 2001
From: Michael Haubenwall
rom 45e0fb72fea4fe32f572265c55135ff4dbd853ad Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner
Date: Tue, 5 Jun 2018 12:40:21 +0200
Subject: [PATCH] fork: remove cygpid.N sharedmem on fork failure
When fork finally fails although both CreateProcess and creating the
"cygpid.N" shared m
On 06/05/2018 03:05 PM, Michael Haubenwallner wrote:
> Hi,
>
> I'm using attached patch for a while now, and orphan cygpid.N shared memory
> instances are gone for otherwise completely unknown windows process ids.
>
> However, I do see defunct processes now which's PPID d
On 06/22/2018 12:25 PM, Corinna Vinschen wrote:
> On Jun 22 11:04, Michael Haubenwallner wrote:
>> On 06/21/2018 09:27 AM, Corinna Vinschen wrote:
>>> On Jun 20 17:47, Michael Haubenwallner wrote:
>>>> On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
>>>&g
On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
> On Jun 5 15:05, Michael Haubenwallner wrote:
>> Hi,
>>
>> I'm using attached patch for a while now, and orphan cygpid.N shared memory
>> instances are gone for otherwise completely unknown windows process ids.
>
On 06/21/2018 09:27 AM, Corinna Vinschen wrote:
> On Jun 20 17:47, Michael Haubenwallner wrote:
>> On 06/07/2018 10:19 AM, Corinna Vinschen wrote:
>>> On Jun 5 15:05, Michael Haubenwallner wrote:
>>>> Hi,
>>>>
>>>> I'm using attached pa
On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> On Apr 1 16:56, Corinna Vinschen wrote:
>> On Apr 1 16:28, Michael Haubenwallner wrote:
>>> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
>>>> can you please collect the base addresses of all DLLs generated during
&
Hi Brian, hi Achim,
Thanks a lot for your input!
On 3/30/19 5:09 PM, Brian Inglis wrote:
> On 2019-03-30 02:22, Achim Gratz wrote:
>> Brian Inglis writes:
>>> On 2019-03-29 14:23, Achim Gratz wrote:
Brian Inglis writes:
>> If you are packaging your own exes and dlls with your own local
Hi Corinna,
On 3/26/19 7:28 PM, Corinna Vinschen wrote:
> On Mar 26 19:25, Corinna Vinschen wrote:
>> Hi Michael,
>>
>>
>> Redirected to cygwin-patches...
>>
>>
>> On Mar 26 18:10, Michael Haubenwallner wrote:
>>> Hi Corinna,
>>>
On 3/28/19 10:58 AM, Corinna Vinschen wrote:
> On Mar 28 10:17, Michael Haubenwallner wrote:
>> As it is not some other dll being loaded at the colliding adress: any
>> idea how to find out _what_ is allocated there (in the forked child),
>> to find out whether we can reserve
On 3/28/19 9:34 AM, Michael Haubenwallner wrote:
> On 3/27/19 10:16 AM, Corinna Vinschen wrote:
>> On Mar 27 09:26, Michael Haubenwallner wrote:
>>> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
>>>> On Mar 26 19:25, Corinna Vinschen wrote:
>>>>>
Hi Corinna,
On 3/27/19 10:16 AM, Corinna Vinschen wrote:
> On Mar 27 09:26, Michael Haubenwallner wrote:
>> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
>>> On Mar 26 19:25, Corinna Vinschen wrote:
>>>> On Mar 26 18:10, Michael Haubenwallner wrote:
>>>&
Hi Achim,
On 3/27/19 8:59 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> As far as I understand, rebasing is about touching already installed
>> dlls as well, which would require to restart all Cygwin processes.
>> As the problem is about some dll built duri
On 3/28/19 10:15 AM, Corinna Vinschen wrote:
> On Mar 28 09:34, Michael Haubenwallner wrote:
>> Hi Corinna,
>>
>> On 3/27/19 10:16 AM, Corinna Vinschen wrote:
>>> On Mar 27 09:26, Michael Haubenwallner wrote:
>>>> On 3/26/19 7:28 PM, Corinna Vinschen wrote
On 3/28/19 4:19 PM, Brian Inglis wrote:
> On 2019-03-28 08:59, Michael Haubenwallner wrote:
>> On 3/27/19 8:59 PM, Achim Gratz wrote:
>>> Michael Haubenwallner writes:
>>>> As far as I understand, rebasing is about touching already installed
>>>> dlls a
On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> On Apr 1 16:56, Corinna Vinschen wrote:
>> On Apr 1 16:28, Michael Haubenwallner wrote:
>>> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
>>>> can you please collect the base addresses of all DLLs generated during
&
Hi Corinna,
On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> On Mar 28 12:48, Michael Haubenwallner wrote:
>> On 3/28/19 10:58 AM, Corinna Vinschen wrote:
>>> On Mar 28 10:17, Michael Haubenwallner wrote:
>>>> As it is not some other dll being loaded at the colli
On 4/3/19 2:26 PM, Corinna Vinschen wrote:
> On Apr 3 12:38, Michael Haubenwallner wrote:
>> Furthermore, with so called "Stacked Prefix", it is possible to have a second
>> level of Gentoo Prefix, so what I'm after is some option to tell the rebase
>> utility wh
On 4/3/19 2:28 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> Before I really can tell what I need regarding the rebase, I need to learn
>> what
>> exactly is recorded into the rebase database, and probably how the recorded
>> data
>> does influen
---
rebase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rebase.c b/rebase.c
index ca3c59d..56537d6 100644
--- a/rebase.c
+++ b/rebase.c
@@ -1441,7 +1441,7 @@ is_rebaseable (const char *pathname)
fd = open (pathname, O_RDONLY);
if (fd == -1)
-goto done;
+
On 4/8/19 7:09 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> Well... once installed, a dll may get in use quickly, because I can not
>> require
>> to shut down all Cygwin processes. So I need to rebase and register the dll
>> in
>> some staging
Some distros prefer a POSIX shell other than /bin/ash and /bin/dash.
---
Makefile.in | 4 ++--
configure.ac | 22 +-
peflagsall.in | 2 +-
rebaseall.in | 2 +-
4 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/Makefile.in b/Makefile.in
index
Rather than newest last write time of all dlls loaded, use the forking
process' windows pid and windows thread id as directory name to create
the forkable hardlinks into. While this may create hardlinks more
often, it does avoid conflicts between dlls not having the newest last
write time.
---
The --no-rebase flag is to update the database for new files, without
performing a rebase. The file names provided should have been rebased
using the --oblivious flag just before.
---
rebase.c | 48 +++-
1 file changed, 35 insertions(+), 13
Otherwise, when the child does fail to reload dlls and terminates, we
produce a SIGCHILD signal, even if we did not succeed in starting up the
child process at all. Also, we would need to reap that child somewhere.
---
winsup/cygwin/fork.cc | 71 ---
1
gt;>
>>>> Back to the drawing board I've never looked at the cygserver code, but
>>>> maybe it will turn out to be something easy.
>>>
>>> Good news (for me): This isn't related to my pipe code. The same problem
>>> occurs
>>>
Querying the ntlength and existence of the /var/run/cygfork directory in
the very first Cygwin process should not use nt_max_path_buf, as that
one is used by dll_list::alloc already.
---
winsup/cygwin/forkable.cc | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
---
winsup/cygwin/dll_init.h | 1 -
winsup/cygwin/forkable.cc | 23 ---
2 files changed, 24 deletions(-)
diff --git a/winsup/cygwin/dll_init.h b/winsup/cygwin/dll_init.h
index e4fbde867..3c274cf35 100644
--- a/winsup/cygwin/dll_init.h
+++ b/winsup/cygwin/dll_init.h
@@
Do not remember the child before it was successfully initialized, or we
would need more sophisticated cleanup on child initialization failure,
like cleaning up the process table and suppressing SIGCHILD delivery
with multiple threads ("waitproc") involved.
---
winsup/cygwin/fork.cc | 33
Pause the child process after performing fork fixups even if there were
no dynamically loaded dlls with extra data/bss transfers to wait for.
This allows the parent process to cancel the current fork call even if
the child process was successfully initialized already.
This is a preparation for
Make stat_real_file_once a method of struct dll, to be more flexible on
where to use. Also, debug print memory section name queried for a dll.
This is a preparation to query the file id when loading the dll.
---
winsup/cygwin/dll_init.h | 1 +
winsup/cygwin/forkable.cc | 22
Querying FILE_BASIC_INFORMATION is needless since using win pid+threadid
for forkables dirname rather than newest last write time.
---
winsup/cygwin/dll_init.cc | 1 -
winsup/cygwin/dll_init.h | 1 -
winsup/cygwin/forkable.cc | 7 +++
3 files changed, 3 insertions(+), 6 deletions(-)
diff
NtQueryVirtualMemory for MemorySectionName does not reliable return the
changed dll file name when another process does move the file around,
and we may end up creating forkable hardlinks to wrong dll files.
So query the file id when loading the dll rather than before fork.
---
On 4/30/19 6:07 PM, Corinna Vinschen wrote:
> On Apr 30 09:09, Michael Haubenwallner wrote:
>> Do not remember the child before it was successfully initialized, or we
>> would need more sophisticated cleanup on child initialization failure,
>> like cleaning up the process
On 5/4/19 4:33 PM, Brian Inglis wrote:
> On 2019-05-03 09:32, Michael Haubenwallner wrote:
>> On 4/12/19 8:03 PM, Corinna Vinschen wrote:
>>> On Apr 12 15:52, Michael Haubenwallner wrote:
>>>> The --no-rebase flag is to update the database for new files, witho
On 4/12/19 8:03 PM, Corinna Vinschen wrote:
> On Apr 12 15:52, Michael Haubenwallner wrote:
>> The --no-rebase flag is to update the database for new files, without
> Wouldn't something like --merge-files be more descriptive?
What about --recognize ?
Thanks!
/
NtQueryVirtualMemory for MemorySectionName may return some old path even
if the process was just started, for when some directory in between was
renamed - maybe because the NT file cache is hot for the old path still.
This was seen during gcc bootstrap, returning a MemorySectionName of
On 4/12/19 7:40 PM, Corinna Vinschen wrote:
> Hi Michael,
> Nick Clifton, one of the binutils maintainers, made the following
> suggestion in PM:
>
> Allow the ld flag --enable-auto-image-base to take a filename as
> argument.>
> The idea: The file is used by ld to generate the start address
>
On 4/10/19 2:32 PM, Michael Haubenwallner wrote:
> On 4/10/19 11:02 AM, Corinna Vinschen wrote:
>> On Apr 9 11:23, Michael Haubenwallner wrote:
>>> Some distros prefer a POSIX shell other than /bin/ash and /bin/dash.
>>
>> I think this is pretty old stuff nobod
On 4/10/19 11:02 AM, Corinna Vinschen wrote:
> On Apr 9 11:23, Michael Haubenwallner wrote:
>> Some distros prefer a POSIX shell other than /bin/ash and /bin/dash.
>
> I think this is pretty old stuff nobody really looked at for a while.
> ash and dash are the same binary any
On 4/13/19 9:36 AM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> On Apr 12 15:32, Michael Haubenwallner wrote:
>>> Rather than newest last write time of all dlls loaded, use the forking
>>> process' windows pid and windows thread id as directory name to create
On 4/13/19 9:38 AM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> The --no-rebase flag is to update the database for new files, without
>> performing a rebase. The file names provided should have been rebased
>> using the --oblivious flag just before.
>
> Th
Do not attach to the child before it was successfully initialized, or we
would need more sophisticated cleanup on child initialization failure,
like suppressing SIGCHILD delivery with multiple threads ("waitproc")
involved.
Improves "Cygwin: fork: Remember child not before success.",
commit
During fork, the child process requires the process table to be
initialized for fixup_shms_after_fork, while still allowing subsequent
dlls.load_after_fork to fail silently (for when the "forkable" hardlinks
are not created yet).
Prepares to improve "Cygwin: fork: Remember child not before
Hi,
following up https://cygwin.com/ml/cygwin-patches/2019-q2/msg00155.html
It turns out that fixup_shms_after_fork does require the child pinfo to
be "remember"ed, while the fork retry to be silent on failure requires
the child to not be "attach"ed yet.
As current pinfo.remember performs both
Hi Corinna,
On 7/30/19 6:07 PM, Corinna Vinschen wrote:
> Hi Michael,
>
> On Jul 30 17:22, Michael Haubenwallner wrote:
>> Hi,
>>
>> following up
>> https://cygwin.com/ml/cygwin-patches/2019-q2/msg00155.html
>>
>> It turns out that fixup
During fork, the child process requires the process table to be
initialized for fixup_shms_after_fork, while still allowing subsequent
dlls.load_after_fork to fail silently (for when the "forkable" hardlinks
are not created yet).
pinfo::remember not performing reattach anymore requires explicit
Do not attach to the child before it was successfully initialized, or we
would need more sophisticated cleanup on child initialization failure,
like suppressing SIGCHILD delivery with multiple threads ("waitproc")
involved.
Improves "Cygwin: fork: Remember child not before success.",
commit
Adding default winvar 'PATH=C:\cygwin64\binZ' to an environment that is
already allocated for 'SYSTEMROOT=ZWINDIR=Z', we need to count that
trailing (Z)ero as well. Otherwise we trigger this assertion failure:
$ /bin/env -i SYSTEMROOT= WINDIR= /bin/env
assertion "(s - envblock) <= tl" failed:
Various registry values do rely on the %SystemDrive% env var to be set.
Right now, it is not known to be easily possible to query the value of
SYSTEMDRIVE environment variable other than preserving the original
environment value even across 'env -i', for use cases like the one in:
On 7/31/19 7:25 PM, Ken Brown wrote:
> On 7/31/2019 12:59 PM, Corinna Vinschen wrote:
>> On Jul 31 12:35, Michael Haubenwallner wrote:
>>> On 7/30/19 6:07 PM, Corinna Vinschen wrote:
>>>> On Jul 30 17:22, Michael Haubenwallner wrote:
>>>>> Hi,
>>
On 8/8/19 10:55 AM, corinna-cyg...@cygwin.com wrote:
> From: Corinna Vinschen
>
> This avoids collisions of shmat maps with Windows own datastructures
> when allocating top-down.
>
> This patch moves the mmap_allocator class definition into its
> own files and just uses it from mmap and shmat.
Hi Takashi,
On 11/11/19 10:17 AM, Corinna Vinschen wrote:
> On Nov 8 22:42, Takashi Yano wrote:
>> I came up with another alternative. How about the attached
>> patch? This forcibly redraws screen when the first native
>> program is executed after creating new pty (pseudo console),
>> instead
Hi Takashi,
On 10/18/19 1:37 PM, Takashi Yano wrote:
> ---
> winsup/cygwin/fhandler_tty.cc | 21 -
> winsup/cygwin/tty.cc | 1 +
> winsup/cygwin/tty.h | 1 +
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git
On 10/22/19 10:04 AM, Corinna Vinschen wrote:
> On Oct 22 09:20, Michael Haubenwallner wrote:
>> On 10/18/19 1:37 PM, Takashi Yano wrote:
>>> + const char *term = getenv ("TERM");
>>> + if (term && strcmp (term, "dumb") && !
On 10/22/19 12:06 PM, Michael Haubenwallner wrote:
> On 10/22/19 10:04 AM, Corinna Vinschen wrote:
>> On Oct 22 09:20, Michael Haubenwallner wrote:
>>> On 10/18/19 1:37 PM, Takashi Yano wrote:
>
>>>> + const char *term = getenv ("TERM");
On 10/17/19 4:55 PM, Ken Brown wrote:
> On 10/16/2019 8:34 AM, Takashi Yano wrote:
>> ---
>> winsup/cygwin/fhandler_tty.cc | 26 +-
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
>>
On 10/3/19 12:43 PM, Takashi Yano wrote:
> - After commit 41864091014b63b0cb72ae98281fa53349b6ef77, there is a
> regression in signal handling reported in
> https://www.cygwin.com/ml/cygwin/2019-10/msg00010.html. This patch
> fixes the issue.
Confirmed, this patch fixes the issue.
Thanks!
88 matches
Mail list logo
