Linda Walsh wrote:
> There...now you've done it. You had me break 'gdb'.
Alright, let me see if I can summarize this entire failure into
something that's hopefully repeatable by anyone looking to reproduce it:
- The reduced testcase is: int main(int, char **) { fork(); }
- Working directory of the process that calls the testcase does not
matter.
- When the testcase's parent process is a Cygwin process, or if the
testcase's parent is a native process but the grandparent is a Cygwin
process [i.e. there's a cygexec helper], then everything is fine.
- When the testcase's binary is located anywhere but %windir% or
%windir%\system32, then everything is fine.
- Otherwise you get:
3690 [main] gvim 3196 C:\WINDOWS\system32\gvim.exe: *** fatal error -
fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
7 [main] gvim 1012 C:\WINDOWS\system32\gvim.exe: *** fatal error
- fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
7 [main] gvim 856 C:\WINDOWS\system32\gvim.exe: *** fatal error -
fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
7 [main] gvim 3424 C:\WINDOWS\system32\gvim.exe: *** fatal error
- fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
7 [main] gvim 1804 C:\WINDOWS\system32\gvim.exe: *** fatal error
- fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
7 [main] gvim 804 C:\WINDOWS\system32\gvim.exe: *** fatal error -
fork:
can't reserve memory for stack 0x23CB28 - 0x240000, Win32 error 487
11 [main] gvim 2660 fork: child -1 - died waiting for longjmp
before
initialization, retry 0, exit code 0x100, errno 11
Does that sound correct?
> The child doesn't have much control over the parent on linux
> either. The parent can wait or not, can choose what to share (via clone),
> etc.
Right, the client can (somehow, either through fork or spawn) create
another copy of itself and then terminate such that if the parent is
waiting it can continue. And in this case, the native vim port does not
contain code to do this in "the win32 way" so it can't "put itself into
the background".
> I hear what you are saying...yet did you know that MS
> improved fork and exec performance by 30% in their SFU Unix-compat layer?
> :-). I wonder what 'pains' they go through -- they might have it
> easier and just use straight NT calls rather than Win32. Dunno...
They don't go to any pains. The sad part is that the NT kernel does
support fork semantics. But it only exposes them to the Posix
subsystem, which is what SFU runs in. It doesn't expose them to the
Win32 subsystem. The problem with subsystems is that a process in one
subsystem can have no interaction with a process in a different one,
meaning if Cygwin used the Posix subsystem it wouldn't be able to link
with or call into any Win32 DLLs... which would make it significantly
less useful.
> True, but cmd can choose to do a "spawn+wait" or it can choose
> to do a "spawn" w/nowait. The user either sees cmd effectively stopped, or
> sees an immediate return. For example, if I type run "wmined" (under
> bash), even though "wmined" can't control whether the parent waits or
> not -- it "effectively" does, by "spawning" off a "no-wait copy of itself
> and it exits. The effect or appearance is that "wmined" has controlled
> whether or not the shell "waits" by returning a "bogus" exiting process.
Sorry, I don't know what "wmined" is so this is over my head.
> Well......I just tried a cygwin "find" on /prog for my name,
> pressed control-z several times -- it didn't stop until it finished.
> (it did respond to control-c, but I had cases where control-c didn't see
> to work either -- but those cases may have been winapps). Certainly,
> control-z didn't suspend
Pressing ^Z while find is running works fine for me:
[2]+ Stopped find /usr/bin
I can type fg and find returns where it left off. You may have to be
using a pty (i.e. cmd.exe with CYGWIN=tty or using rxvt) in order to
activate the termios handling that supports this.
> Let's put the gvim "mostly" on the back burner. At this point
> I'll just ask if you have an idea why 'gdb' won't start. From a
> 'completeness' point of view, I'm still wondering why I can't call fork
> in a cygwin program from windows.
The gdb failure could be due to the same thing that's preventing the
fork emulation from working, or it could be something else. C0000022 is
STATUS_ACCESS_DENIED. I'm not sure what else to suggest other than
saying that it needs to be debugged further. I know that's a
meaningless and empty statement without specifics, but it's the kind of
thing where it's hard to give a step by step list of how to go about
debugging. If it were me, I think I would try to trace the process
startup using native tools: Microsoft's windbg or ollydbg,
rohitlab.com's API monitor, Sysinternals' procexp and procmon,
Dependency Walker's startup profiling, those kind of things.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
