Menu
▾
▴
mingw-users
|
From: Ivan K. <mi...@ka...> - 2011-03-15 13:50:12
|
Hello,
I have seen this problem on msys git and posted on their mailing list. I
am bringing it here as I feel it's more appropriate.
I have installed mingw with mingw-get-inst-20110313.exe
When if I run the shell then rm, I get the following error:
C:\MinGW-2011\msys\1.0\bin>sh
sh-3.1$ rm
C:\MinGW-2011\msys\1.0\bin\sh.exe: *** fork: can't reserve memory
for stack 0x4A0000 - 0x6A0000, Win32 error 0
0 [main] sh 2232 sync_with_child: child 2264(0x2AC)
died before initialization with status code 0x1
128 [main] sh 2232 sync_with_child: *** child state waiting for longjmp
sh: fork: Resource temporarily unavailable
Johannes Schindelin from msys git suggested I run the following command
rebase -b 0x67000000 msys-1.0.dll
It didn't work. I upgraded from SP1 to SP2 and it didn't change
anything.
I had a little look at the code in mingwrt on CVS. I grepped around for
a function called fork and I was surprised that it didn't exist.
Any help will be much appreciated!
Kind regards,
--
Ivan Kanis, Release Manager, Vision Objects,
Tel +33 2 28 01 84 44, Fax +33 2 40 25 89 20
http://www.visionobjects.com
There are some experiences in life which should not be demanded twice
from any man, and one of them is listening to the Brahms Requiem.
-- George Bernard Shaw
|
|
From: Peter R. <p.r...@sh...> - 2011-03-15 14:06:00
|
On 15/03/11 13:25, Ivan Kanis wrote: > Hello, > > I have seen this problem on msys git and posted on their mailing list. I > am bringing it here as I feel it's more appropriate. > > I have installed mingw with mingw-get-inst-20110313.exe > > When if I run the shell then rm, I get the following error: > > C:\MinGW-2011\msys\1.0\bin>sh > sh-3.1$ rm > C:\MinGW-2011\msys\1.0\bin\sh.exe: *** fork: can't reserve memory > for stack 0x4A0000 - 0x6A0000, Win32 error 0 > 0 [main] sh 2232 sync_with_child: child 2264(0x2AC) > died before initialization with status code 0x1 > 128 [main] sh 2232 sync_with_child: *** child state waiting for longjmp > sh: fork: Resource temporarily unavailable > > Johannes Schindelin from msys git suggested I run the following command > > rebase -b 0x67000000 msys-1.0.dll > > It didn't work. I upgraded from SP1 to SP2 and it didn't change > anything. > > I had a little look at the code in mingwrt on CVS. I grepped around for > a function called fork and I was surprised that it didn't exist. > > Any help will be much appreciated! > > Kind regards, Have a look at http://www.mingw.org, in particular, the bit that says: "*MinGW* compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes. *MinGW*, being Minimalist, *does not, and never will, attempt to provide a POSIX runtime environment for POSIX application deployment on MS-Windows*. If you want POSIX application deployment on this platform, please consider Cygwin <http://www.cygwin.com> instead." P. |
|
From: LRN <lr...@gm...> - 2011-03-15 14:24:07
|
On 15.03.2011 17:05, Peter Rockett wrote: > On 15/03/11 13:25, Ivan Kanis wrote: >> Hello, >> >> I have seen this problem on msys git and posted on their mailing list. I >> am bringing it here as I feel it's more appropriate. >> >> I have installed mingw with mingw-get-inst-20110313.exe >> >> When if I run the shell then rm, I get the following error: >> >> C:\MinGW-2011\msys\1.0\bin>sh >> sh-3.1$ rm >> C:\MinGW-2011\msys\1.0\bin\sh.exe: *** fork: can't reserve memory >> for stack 0x4A0000 - 0x6A0000, Win32 error 0 >> 0 [main] sh 2232 sync_with_child: child 2264(0x2AC) >> died before initialization with status code 0x1 >> 128 [main] sh 2232 sync_with_child: *** child state waiting for >> longjmp >> sh: fork: Resource temporarily unavailable >> >> Johannes Schindelin from msys git suggested I run the following command >> >> rebase -b 0x67000000 msys-1.0.dll >> >> It didn't work. I upgraded from SP1 to SP2 and it didn't change >> anything. >> >> I had a little look at the code in mingwrt on CVS. I grepped around for >> a function called fork and I was surprised that it didn't exist. >> >> Any help will be much appreciated! >> >> Kind regards, > > Have a look at http://www.mingw.org, in particular, the bit that says: > > "*MinGW* compilers provide access to the functionality of the > Microsoft C runtime and some language-specific runtimes. *MinGW*, > being Minimalist, *does not, and never will, attempt to provide a > POSIX runtime environment for POSIX application deployment on > MS-Windows*. If you want POSIX application deployment on this > platform, please consider Cygwin <http://www.cygwin.com> instead." > > P. I think what he meant is: MinGW does not provide POSIX-compatible environment, Msys does. Cygwin also does. Msys is based on an old version of Cygwin, actually. But that's besides the point. I'm not sure rebasing would help (fork issues can be caused by base address conflicts, but this is unlikely to be the case here). Are you sure you AREN'T running out of memory? Msys tends to conflict with certain drivers in Windows, causing constant memory leaks that can't be recovered without rebooting (seen that one myself). Does this problem happen after a fresh reboot, if you immediately run msys and rm? |
|
From: Charles W. <cwi...@us...> - 2011-03-15 14:33:22
|
Peter -- please refrain from using HTML when posting to this list. Thanks.
On 3/15/2011 10:05 AM, Peter Rockett wrote:
> On 15/03/11 13:25, Ivan Kanis wrote:
>> I have seen this problem on msys git and posted on their mailing list. I
>> am bringing it here as I feel it's more appropriate.
>>
>> I have installed mingw with mingw-get-inst-20110313.exe
>>
>> When if I run the shell then rm, I get the following error:
>>
>> C:\MinGW-2011\msys\1.0\bin>sh
>> sh-3.1$ rm
>> C:\MinGW-2011\msys\1.0\bin\sh.exe: *** fork: can't reserve memory
>> for stack 0x4A0000 - 0x6A0000, Win32 error 0
>> 0 [main] sh 2232 sync_with_child: child 2264(0x2AC)
>> died before initialization with status code 0x1
>> 128 [main] sh 2232 sync_with_child: *** child state waiting for longjmp
>> sh: fork: Resource temporarily unavailable
Ivan --
This is the dreaded fork sync_with_child error. The MSYS DLL, which is
used to provide posix services to many of the unix ports we supply,
emulates the POSIX fork() system call.
Now, this gets to the very heart of one of the major differences between
unix and windows: process management.
On Windows, if one processs (application) wants to start another one, it
uses CreateProcess() to do so -- and the OS creates a brand new process,
populates its memory with the specified EXE, loads all the correct DLLs
for that EXE into the EXE's memory map, and executes its entry point (main).
On unix, the parent process instead "forks" itself -- creating two
identical copies of the same process, with exactly the same memory map,
all the same DLLs loaded in all the same places. In fact, everything is
identical -- except that in the child copy, the fork() call returns '0',
and in the parent copy, the fork() call returns the process id of the
child. The child then calls "exec()" which basically says: replace "me"
with the following application, and execute its entry point (main).
So, to emulate the fork/exec model of unix, on windows, fork() must (a)
use CreateProcess("parent application") with a bunch of special flags so
that the new process doesn't actually start running. Then, it needs to
copy the entire memory map of the parent process into the child
process's memory -- AND ensure that the child process gets all the same
DLLs loaded in all the same places. There's also a bunch of
parent/child synchronization issues that have to occur.
The problem is, MSYS is not in control of the process of actually
loading the DLLs into the child process's memory space -- so we have to
rely on the OS "getting it right". Here's the process:
1) Every DLL has a specific "image base" -- a memory address that is
the preferred location for that DLL to be loaded. Windows
attempts to use that addr first.
2) If there is a conflict, then one of the DLLs is automatically
"rebased" in memory to a different location, and all internal
pointers updated to reflect the new location.
The problem occurs if a DLL was loaded into the non-default location in
the parent -- but then into the default location in the child (or vice
versa. Or into two different non-default locations in parent and child).
If this occurs, then obviously the memory map of the parent and child
CAN'T be identical -- and fork() fails.
That's what you're seeing.
So, one of the tricks we try to use to make this less likely is to
provide every DLL in the entire MSYS system with a unique,
non-overlapping default image base. The 'rebase' tool can be used to do
this, one at a time, as you have already done with the main MSYS dll
itself. However, you still may need to repeat the process, using a
bunch of different image base addrs, for all the OTHER dlls. The
rebaseall script can help you there. See the documentation in
/usr/share/doc/MSYS/rebase*.README.txt
There's another trick, that may work on Vista and above, which involves
the peflags / peflagsall tools. Again, see the docs.
Finally, another common culprit in this problem are ill-behaved anti
virus utilities. These tend to "hook" special DLLs into the parent
executable's memory map, where MSYS doesn't know about them and can't
ensure they are replicated in the child. Check the Big List of Dodgy
Apps (BLODA) over at cygwin:
http://cygwin.com/faq/faq.using.html#faq.using.bloda
>> Johannes Schindelin from msys git suggested I run the following command
>>
>> rebase -b 0x67000000 msys-1.0.dll
Err...rebase is an MSYS application, so it will be unable to change the
image base of the msys-1.0.dll since the very act of using the exe means
the DLL is "in-use". Unless you're using some OTHER implementation of
rebase, such as the one from MS, or from cygwin.
>> It didn't work. I upgraded from SP1 to SP2 and it didn't change
>> anything.
>>
>> I had a little look at the code in mingwrt on CVS. I grepped around for
>> a function called fork and I was surprised that it didn't exist.
Right...fork() is part of the MSYS dll, which provides runtime (C
library) services for msys (that is, posix on windows; like cygwin)
applications. It is not part of the mingw runtime, which provides
runtime (C library) services for native, win32, applications.
Since sh.exe is an msys app, it uses MSYS dll, and (tries to) use fork()
when launching other applications.
> Have a look at http://www.mingw.org, in particular, the bit that says:
>
> "*MinGW* compilers provide access to the functionality of the Microsoft
> C runtime and some language-specific runtimes. *MinGW*, being
> Minimalist, *does not, and never will, attempt to provide a POSIX
> runtime environment for POSIX application deployment on MS-Windows*. If
> you want POSIX application deployment on this platform, please consider
> Cygwin <http://www.cygwin.com> instead."
Peter --
>From reading Ivan's original message, it does not appear that he is
trying to port some unix app to mingw, and is tripping over the fact
that mingw doesn't have fork(). Rather, it appears he is trying to use
*our* MSYS tools and they are failing to operate correctly due to the
dreaded fork/sync_with_child error. So...your reply to Ivan is kinda
off point.
--
Chuck
|
|
From: Ivan K. <mi...@ka...> - 2011-03-16 10:10:10
|
Hi, I was using %SystemRoot%\system32\cmd.exe instead of %WINDIR%\SysWOW64\cmd.exe as my shell. I stumbled on the solution by looking at msys.bat. Charles, thanks for your detailed explanations it was very instructive. Take care, -- Ivan Kanis, Release Manager, Vision Objects, Tel +33 2 28 01 84 44, Fax +33 2 40 25 89 20 http://www.visionobjects.com We meet no Stranger, but Ourself. -- Emily Dickinson |
|
From: Greg C. <gch...@sb...> - 2011-03-15 14:33:24
|
On 2011-03-15 13:25Z, Ivan Kanis wrote: > > C:\MinGW-2011\msys\1.0\bin>sh > sh-3.1$ rm Normally, of course, you wouldn't run exactly those commands. But I'd expect rm: missing operand rather than this a fork() failure. > C:\MinGW-2011\msys\1.0\bin\sh.exe: *** fork: can't reserve memory > for stack 0x4A0000 - 0x6A0000, Win32 error 0 > 0 [main] sh 2232 sync_with_child: child 2264(0x2AC) > died before initialization with status code 0x1 > 128 [main] sh 2232 sync_with_child: *** child state waiting for longjmp > sh: fork: Resource temporarily unavailable > > Johannes Schindelin from msys git suggested I run the following command > > rebase -b 0x67000000 msys-1.0.dll In this situation, running 'rebase' would often fix the problem. > It didn't work. Were any MSYS programs (such as bash) running when you tried it? Did it print any diagnostics? Did you try a different base address than 0x67000000? Have you ruled out BLODA? http://cygwin.com/faq/faq.using.html#faq.using.bloda > I had a little look at the code in mingwrt on CVS. I grepped around for > a function called fork and I was surprised that it didn't exist. 'mingwrt' contains headers and import libraries for windows-native programming, so it doesn't have fork(). MSYS has its own distinct runtime library which would include fork(). |
