Hi Camm,
On 4/23/2025 12:46 PM, Camm Maguire via Cygwin wrote:
Greetings! Trying to isolate this as you suggest. On first attempt,
copying the exact same strings and calls into a main() function
succeeds. I am near stumped, and can only guess that the addresses
returned by malloc on _init of
gt; spawn 2e FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
> spawn 2e PROCESSOR_ARCHITECTURE=AMD64
> spawn 2e PUBLIC=C:\Users\Public
> spawn 2e SYSTEMDRIVE=C:
> spawn 2e EXECIGNORE=*.dll
> spawn 2e OLDPWD=/cygdrive/c/Users/cammm/32/gclm/gcl/gcl
> spawn 2e ProgramData=C:\ProgramData
> spawn 2e emac
Hi Camm,
On 4/22/2025 12:31 PM, Camm Maguire via Cygwin-apps wrote:
Greetings! posix_spawnp is returning 10, or ECHILD, on the following
call. At least on my first reading (:-)), ECHILD is not one of the
documented errors for fork, vfork, or clone referenced by the Linux
manpage for posix_spaw
,
=
massert(!posix_spawn_file_actions_init(&file_actions));
massert(!posix_spawnattr_init(&attr));
printf("spawn 2 %s\n",*p1);
for (pp=p1;pp writes:
> On 4/19/2025 1:42 PM, Camm Maguire via Cygwin-apps wrote:
>> Greetings!
>
Greetings, and thanks so much!
Mark Geisert via Cygwin-apps writes:
> On 4/19/2025 1:42 PM, Camm Maguire via Cygwin-apps wrote:
>> Greetings!
>> posix_spawn is returning non-zero without setting errno:
>>massert(!posix_spawnp(&pid, *p1, &file_actions, &attr,
On 4/19/2025 1:42 PM, Camm Maguire via Cygwin-apps wrote:
Greetings!
posix_spawn is returning non-zero without setting errno:
massert(!posix_spawnp(&pid, *p1, &file_actions, &attr, (void *)p1,
environ));
Is this intended to be supported? Is it known to be working or
In the doc tree, change the title of section "Other UNIX system
> > > > interfaces..." to "Other system interfaces...". Add the spawn family of
> > > > functions noting their origin as Windows.
> > >
> > > re spawn() family: Cygwin
; interfaces..." to "Other system interfaces...". Add the spawn family of
> > > functions noting their origin as Windows.
> >
> > re spawn() family: Cygwin posix_spawn() seems to rely on the rather
> > inefficient vfork(), while Opengroup intended it t
On Mon, 17 Feb 2025, Corinna Vinschen wrote:
> The requirements of posix_spawn and their helper functions are so
> that we can't easily fulfill them without doing the fork/exec
> twist.
>
> See https://man7.org/linux/man-pages/man3/posix_spawn.3.html.
> Windows CreatePro
; > functions noting their origin as Windows.
>
> re spawn() family: Cygwin posix_spawn() seems to rely on the rather
> inefficient vfork(), while Opengroup intended it to be an API to
> Windows spawn().
>
> Is there a technical limitation why Cygwin posix_spawn() cannot use
>
On Sun, 16 Feb 2025 at 22:47, Mark Geisert wrote:
>
> In the doc tree, change the title of section "Other UNIX system
> interfaces..." to "Other system interfaces...". Add the spawn family of
> functions noting their origin as Windows.
re spawn() family: Cygwi
On 6/6/2024 4:09 PM, Dan Shelton via Cygwin wrote:
On Wed, 6 Mar 2024 at 01:08, Mark Geisert via Cygwin wrote:
On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:
[...]
posix_spawn() was added to POSIX so a Win32 implementation can use Win32 spawn()
...now I see what you're getting at
t; >>> strace does not help, as I need the Win32 calls BELOW posix_spawn(),
> >>> to see the implementation details.
> >>
> >> Check the source code, then. It's at:
> >> https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc
> &
race does not help, as I need the Win32 calls BELOW posix_spawn(),
> >>> to see the implementation details.
> >>
> >> Check the source code, then. It's at:
> >> https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc
> >>
> >&
On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:
On Mon, 4 Mar 2024 at 07:45, Mark Geisert via Cygwin wrote:
On 3/3/2024 7:27 PM, Dan Shelton via Cygwin wrote:
[...]
strace does not help, as I need the Win32 calls BELOW posix_spawn(),
to see the implementation details.
Check the source
ue, 27 Feb 2024 at 06:47, Brian Inglis via Cygwin
> >>> wrote:
> >>>>
> >>>> On 2024-02-26 20:23, Dan Shelton via Cygwin wrote:
> >>>>> Does Cygwin implement a native, i.e. without form(),exec(),
> >>>>> implementation of po
implement a native, i.e. without form(),exec(), implementation of
posix_spawn()?
Check the API compatibility docs online:
https://cygwin.com/cygwin-api/compatibility.html#std-susv4
or optional locally installed package cygwin-doc:
/usr/share/doc/cygwin-doc/html/cygwin-api
t; > > Does Cygwin implement a native, i.e. without form(),exec(),
> > > > implementation of posix_spawn()?
> > >
> > > Check the API compatibility docs online:
> > >
> > > https://cygwin.com/cygwin-api/compatibility.html#std-susv4
> &g
),
> > > implementation of posix_spawn()?
> >
> > Check the API compatibility docs online:
> >
> > https://cygwin.com/cygwin-api/compatibility.html#std-susv4
> >
> > or optional locally installed package cygwin-doc:
> >
> >
> >
On Tue, 27 Feb 2024 at 06:47, Brian Inglis via Cygwin wrote:
>
> On 2024-02-26 20:23, Dan Shelton via Cygwin wrote:
> > Does Cygwin implement a native, i.e. without form(),exec(), implementation
> > of posix_spawn()?
>
> Check the API compatibility docs online:
>
&
On 2024-02-26 20:23, Dan Shelton via Cygwin wrote:
Does Cygwin implement a native, i.e. without form(),exec(), implementation of
posix_spawn()?
Check the API compatibility docs online:
https://cygwin.com/cygwin-api/compatibility.html#std-susv4
or optional locally installed package
Hello!
Does Cygwin implement a native, i.e. without form(),exec(),
implementation of posix_spawn()?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https
Hi Eric,
On Jul 31 13:58, Eric Blake via Cygwin wrote:
> Following up on an older thread:
>
> On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote:
> > The glibc bug points to the sample posix_spawn() implementation in
> > POSIX XRAT - but that example implementation
Following up on an older thread:
On Tue, Apr 18, 2023 at 03:49:20PM -0500, Eric Blake wrote:
> The glibc bug points to the sample posix_spawn() implementation in
> POSIX XRAT - but that example implementation is non-normative and
> known buggy, so it is not safe to rely on it.
>
>
disagree on which handles they want to be inherited?"
> > The answer, overlooked in the article, is to use DuplicateHandle
> > and set the inheritability of the duplicate to true. Concurrently
> > running posix_spawn invocations in other threads will not see the
> > duplic
On Thu, Apr 20, 2023 at 03:14:59AM -0400, gs-cygwin@gluelogic.com wrote:
> On Mon, Apr 17, 2023 at 08:44:51PM +0200, Bruno Haible via Cygwin wrote:
> > Btw, there are two more functions in the posix_spawn family meanwhile:
> > * posix_spawn_file_actions_addchdir_np
> &g
ng still had a fatal flaw: What
>if two threads within the same process both call CreateProcess but
>disagree on which handles they want to be inherited?"
> The answer, overlooked in the article, is to use DuplicateHandle
> and set the inheritability of the duplicate to tr
inherited?"
The answer, overlooked in the article, is to use DuplicateHandle
and set the inheritability of the duplicate to true. Concurrently
running posix_spawn invocations in other threads will not see the
duplicates, since they only see HANDLEs that are assigned to file
descriptors, not HA
On Thu, Apr 20, 2023 at 05:40:52PM +0200, Corinna Vinschen via Cygwin wrote:
> On Apr 20 16:58, Bruno Haible via Cygwin wrote:
> > Corinna Vinschen wrote:
> > > > Hmm. Your code uses lpReserved2 for that, but the functionality is
> > > > one implemented in MSVCRT. For obvious reasons, Cygwin exec
BUTE_HANDLE_LIST argument described in
> >
> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
>
> Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3,
> instead of lpReserved2
t; > arbitrary reshuffling of file descriptors required by posix_spawn
> > > (the addopen, adddup2, addclose actions), i.e. which does the book-
> > > keeping which HANDLE must in the end be open in the parent and which
> > > must in the end be open in
On Apr 20 16:58, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > > Hmm. Your code uses lpReserved2 for that, but the functionality is
> > > one implemented in MSVCRT. For obvious reasons, Cygwin executables
> > > are not linked against msvcrt.dll and we're using lpReserved2 for our
>
eadattribute
Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3,
instead of lpReserved2 — albeit without associated 'flags'. Not sure how
O_APPEND is handled then... (Note: O_APPEND behaviour is tested by
gnulib/tests/test-posix_spawn-open2.c.)
I had see
On Apr 20 16:21, Corinna Vinschen via Cygwin wrote:
> On Apr 20 12:18, Bruno Haible via Cygwin wrote:
> > The "inheritable handles" is a data structure that allows for the
> > arbitrary reshuffling of file descriptors required by posix_spawn
> >
On Apr 20 12:18, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > Unfortunately you can't expect any noticable difference on Cygwin by
> > using posix_spawn. While Cygwin has a spawn() family of functions, we
> > don't (and can't... yet) use them.
&
Corinna Vinschen wrote:
> Unfortunately you can't expect any noticable difference on Cygwin by
> using posix_spawn. While Cygwin has a spawn() family of functions, we
> don't (and can't... yet) use them.
>
> The problem is that we don't have a safe way to perf
On Apr 20 03:14, gs-cygwin.com--- via Cygwin wrote:
> On Mon, Apr 17, 2023 at 08:44:51PM +0200, Bruno Haible via Cygwin wrote:
> > Btw, there are two more functions in the posix_spawn family meanwhile:
> > * posix_spawn_file_actions_addchdir_np
> > implemented by glibc
On Mon, Apr 17, 2023 at 08:44:51PM +0200, Bruno Haible via Cygwin wrote:
> Btw, there are two more functions in the posix_spawn family meanwhile:
> * posix_spawn_file_actions_addchdir_np
> implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3
> used by a
On Wed, 19 Apr 2023 at 13:56, Bruno Haible via Cygwin wrote:
> Note a typo: line 126541 is on page 3694 not on page 3594.
>
That sentence is scary in and of itself :)
Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/
Eric Blake wrote:
> POSIX issue now filed as
> https://www.austingroupbugs.net/view.php?id=1674
Thank you very much!
Note a typo: line 126541 is on page 3694 not on page 3594.
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Docum
I wrote:
> * posix_spawn_file_actions_addfchdir_np
> implemented in glibc, musl libc
Correction: posix_spawn_file_actions_addfchdir_np is implemented in
glibc, musl libc, FreeBSD ≥ 13.1, macOS ≥ 10.15.
Bruno
--
Problem reports: https://cygwin.com/problems.html
FAQ:
Hi Bruno,
On Apr 17 20:44, Bruno Haible via Cygwin wrote:
> Btw, there are two more functions in the posix_spawn family meanwhile:
> * posix_spawn_file_actions_addchdir_np
> implemented by glibc [1], musl libc, macOS, FreeBSD [2], Solaris ≥ 11.3
> used by a few packa
On Apr 18 21:39, Eric Blake via Cygwin wrote:
> On Wed, Apr 19, 2023 at 12:10:34AM +0200, Bruno Haible wrote:
> > Eric Blake wrote:
> > > we now have implementations in the wild that differ in behavior, and
> > > use security as a reason for the divergence, it is worth getting that
> > > clarified
On Wed, Apr 19, 2023 at 12:10:34AM +0200, Bruno Haible wrote:
> Eric Blake wrote:
> > we now have implementations in the wild that differ in behavior, and
> > use security as a reason for the divergence, it is worth getting that
> > clarified in POSIX. I'll file a bug against POSIX shortly
>
> Fo
Eric Blake wrote:
> we now have implementations in the wild that differ in behavior, and
> use security as a reason for the divergence, it is worth getting that
> clarified in POSIX. I'll file a bug against POSIX shortly
For the reference, the systems that return ENOEXEC for posix_spawnp
attempti
put, it's highly appreciated.
> > Second, the rational section in POSIX explains posix_spawn and
> > posix_spawnp, but it does *not* actually provide an example
> > implementation of posix_spawnp, only of posix_spawn.
>
> POSIX is silent as to whether posix_spawnp()
ou can set the mode bits, but they are not acted upon.
The glibc bug points to the sample posix_spawn() implementation in
POSIX XRAT - but that example implementation is non-normative and
known buggy, so it is not safe to rely on it.
Clarifying the wording in XRAT to explicitly mention that the examp
Disclaimer: I have done my tests with Cygwin 2.9.0; so, if things have
> >
> > 2017-09-07
> >
> > I'm a bit puzzled. You quote that only Cygwin 3.1.7 has the fixed
> > posix
win 2.9.0; so, if things have
>
> 2017-09-07
>
> I'm a bit puzzled. You quote that only Cygwin 3.1.7 has the fixed
> posix_spawn, but then you test this with a version three years older?
I have now verified that the findings with Cygwin 3.4.6 are the same
Hi Bruno,
On Apr 16 13:46, Bruno Haible via Cygwin wrote:
> Hi,
>
> AFAIU, Cygwin has a working posix_spawn[p] implementation since 2020
> (commit 3fbfcd11fb09d5f47af3043ee47ec5c7d863d872, 2020-08-03,
Hi,
AFAIU, Cygwin has a working posix_spawn[p] implementation since 2020
(commit 3fbfcd11fb09d5f47af3043ee47ec5c7d863d872, 2020-08-03, Cygwin 3.1.7).
Additionally, Gnulib has a posix_spawn[p] implementation since 2022,
that works on all platforms, including native Windows. Based on it,
I
On Jan 12 13:25, Jeremy Drake via Cygwin wrote:
> > > > Sorry, I am not subscribed to the list so don't have the message to
> > > > reply
> > > > to for threading purposes
>
> > New developer snapshot is up at https://cygwin.com/snapshots/
> > Please test.
>
> This works, and make's "make check"
> > > Sorry, I am not subscribed to the list so don't have the message to reply
> > > to for threading purposes
> New developer snapshot is up at https://cygwin.com/snapshots/
> Please test.
This works, and make's "make check" now gets the same results as it does
when built with --disable-posix-s
On 1/12/2022 5:41 AM, Corinna Vinschen wrote:
On Jan 11 16:08, Ken Brown wrote:
I don't have time to check this carefully, but it looks to me like the
problem is that process_spawnattr calls setegid and seteuid instead of
setegid32 and seteuid32. This causes truncation of the gid and uid.
You
On Jan 12 11:41, Corinna Vinschen wrote:
> On Jan 11 16:08, Ken Brown wrote:
> > On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote:
> > > Sorry, I am not subscribed to the list so don't have the message to reply
> > > to for threading purposes, but attached please find a C reproducer that
> > > w
On Jan 11 16:08, Ken Brown wrote:
> On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote:
> > Sorry, I am not subscribed to the list so don't have the message to reply
> > to for threading purposes, but attached please find a C reproducer that
> > works on x86_64 but fails on i686. The particular i
On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote:
Sorry, I am not subscribed to the list so don't have the message to reply
to for threading purposes, but attached please find a C reproducer that
works on x86_64 but fails on i686. The particular issue seems to be the
POSIX_SPAWN_RESETIDS flag
ument" errors. Some debugging revealed that rebuilding
> make resulted in it using posix_spawn now instead of vfork. Passing
> --disable-posix-spawn to make's configure script results in a working i686
> make.
>
> Can you create a simple, self-contained testcase in plain C
nvalid argument" errors. Some debugging revealed that rebuilding
> make resulted in it using posix_spawn now instead of vfork. Passing
> --disable-posix-spawn to make's configure script results in a working i686
> make.
>
> >From the MSYS2 bug report:
>
> "
e resulted in it using posix_spawn now instead of vfork. Passing
--disable-posix-spawn to make's configure script results in a working i686
make.
>From the MSYS2 bug report:
"""
For reference, I tried to rebuild "make" in cygwin 32 bit and it has the
same problem:
Hi Corinna,
On Thu, 2020-08-20 at 14:50 +0200, Corinna Vinschen wrote:
> No, it won't work as expected, as you can see from the discussion in
>
> this thread. Some internal work would be required.
OK. So even with no file actions and spawn atributes, it still would
break things.
What kind of t
On Aug 20 07:40, Peter Dons Tychsen via Cygwin wrote:
> Hi Corinna,
>
> > spawn alone doesn't cut it, due to the requirement to support the
> > additional file actions and spawn atributes POSIX defines. This
> > would require a revamp of Cygwin's spawn functionality, which is
> > already quite co
iles, etc.). Almost all modern
versions of these programs have support for calling posix_spawn()
instead when creating processes, which would (if we changed it) speed
up these cases dramatically if it avoided fork(). It would simply make
cygwin more appealing to this group of users.
Thanks,
/pedro
ll together. One of the things
> bogging down performance on larger setups is the calls to fork() are is
> inherently slow and should be avoided at all costs. Instead why don't
> we just call spawn(vpe) instead, which is quite stable and fast.
>
> This would give a _huge_ boost
should be avoided at all costs. Instead why don't
we just call spawn(vpe) instead, which is quite stable and fast.
This would give a _huge_ boost to e.g. larger build jobs. Make supports
posix_spawn, but it does not help on cygwin at it just calls back into
fork().
The current implementa
On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
> > > > > posix_spawn(p) returns before the spawned process is fully up and
> > > > > running. [...]
> > > > I just took a look at the source, and I see that posix_spawn was taken
> > > > from
> > > &g
Hi Corinna,
On 7/30/2020 1:17 PM, Corinna Vinschen wrote:
Hi Ken,
On Jul 30 13:59, Corinna Vinschen wrote:
On Jul 29 19:12, Ken Brown via Cygwin wrote:
On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
posix_spawn(p) returns before the spawned process is fully up and
running. [...]
I just
Hi Ken,
On Jul 30 13:59, Corinna Vinschen wrote:
> On Jul 29 19:12, Ken Brown via Cygwin wrote:
> > On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
> > > posix_spawn(p) returns before the spawned process is fully up and
> > > running. [...]
> > I just took a l
On Jul 29 19:12, Ken Brown via Cygwin wrote:
> On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
> > posix_spawn(p) returns before the spawned process is fully up and
> > running. [...]
> I just took a look at the source, and I see that posix_spawn was taken from
> FreeBSD.
On 7/29/2020 4:17 PM, Ken Brown via Cygwin wrote:
posix_spawn(p) returns before the spawned process is fully up and running. As a
result, the spawned process can fail to receive signals. The attached test case
illustrates the problem. It spawns a sleep process and then tries to kill it.
On
posix_spawn(p) returns before the spawned process is fully up and running. As a
result, the spawned process can fail to receive signals. The attached test case
illustrates the problem. It spawns a sleep process and then tries to kill it.
On exit, the sleep process is still running.
The
an effect.
The idea is to add upstream support for posix_spawn when it would be
useful. Because posix_spawn is a standardized facility, because other
systems usefully implement it too, and because posix_spawn can be
implemented in terms of fork for systems that lack posix_spawn (with
gnulib provid
On Tue, Jan 03, 2012 at 05:43:30PM -0500, Ryan Johnson wrote:
>On 03/01/2012 5:25 PM, dan...@dancol.org wrote:
>> posix_spawn [1] is an optional POSIX facility that allows programs to
>> start other programs without using fork or vfork. I've created an
>> efficient imp
On 1/3/2012 2:43 PM, Ryan Johnson wrote:
> On 03/01/2012 5:25 PM, dan...@dancol.org wrote:
>> posix_spawn [1] is an optional POSIX facility that allows programs to
>> start other programs without using fork or vfork. I've created an
>> efficient implementation of posix_
On 03/01/2012 5:25 PM, dan...@dancol.org wrote:
posix_spawn [1] is an optional POSIX facility that allows programs to
start other programs without using fork or vfork. I've created an
efficient implementation of posix_spawn for Cygwin. The code is available
at https://github.com/dcolas
posix_spawn [1] is an optional POSIX facility that allows programs to
start other programs without using fork or vfork. I've created an
efficient implementation of posix_spawn for Cygwin. The code is available
at https://github.com/dcolascione/cygspawn.
This library uses Cygwin's n
76 matches
Mail list logo
