#1850 MSYS-1.0.10 crashes on Windows x64


MSYS does not work on Windows x64 at all:

C:\Program Files (x86)\CD-adapco\wingnu\msys\1.0\bin>sh

sh-2.04$ ls

C:\Program Files
(x86)\CD-adapco\wingnu\msys\1.0\bin\sh.exe: *** fork:
can't reserve memory for stack 0x480000 - 0x680000,
Win32 error 0

0 [main] sh 2192 sync_with_child: child
2316(0x2F8) died before
initialization with status code 0x1

177 [main] sh 2192 sync_with_child: *** child state
waiting for longjmp

sh: fork: Resource temporarily unavailable



  • Earnie Boyd

    Earnie Boyd - 2005-06-16
    • priority: 5 --> 1
  • Earnie Boyd

    Earnie Boyd - 2005-06-16

    Logged In: YES

    This is not a bug but a feature request.

    Why would you expect a runtime for a 32 bit OS to work on a
    64 bit OS.

    Patching will be greatfully accepted.

  • Earnie Boyd

    Earnie Boyd - 2005-06-16
    • labels: --> MSYS
  • Earnie Boyd

    Earnie Boyd - 2005-06-16
    • milestone: --> Waiting_for_Patch_Set
  • hob4bit

    hob4bit - 2005-06-16

    Logged In: YES

    Because Windows x64 supports both 32bit and 64bit excutables.
    Actually, we had some technial guy from Microsoft looking at
    this and he said its upto the open soruce community to sort
    it out. Micorsoft will not help us fix MSYS for Windows x64.

    We use MSYS to perform some UNIX shell scripting which
    works okay on Windows 32bit but not Windows x64.


  • Earnie Boyd

    Earnie Boyd - 2005-06-17

    Logged In: YES

    You should look for developers using win64 and have them
    join you in the effort to make it work. This is actually a
    duplicate RFE.

    Ask for help on the mingw-users list. Advertise for help on
    the alexandria - Projects - Help Wanted Forum (one of the SF
    Forums). You may even find an MS employee willing to help
    that is using MSYS (there are a few of those types of users).


  • S. Loisel

    S. Loisel - 2005-07-09

    Logged In: YES


    Over a year ago, Scott Duplichan <sduplichan at yahoo dot
    com> posted an analysis of this problem which might be
    helpful to the cygwin mailing list. You can find it here:

    He claimed to have solved the problem. In summary:

    << The problem seems to originate with the way Win64
    arranges the virtual address space in the new process
    created by fork. In Win32, the virtual address layout
    created by CreateProcess matches the virtual address layout
    from the parent process created by Windows. But in Win64,
    they differ. >>

    He then shows that the stack has changed location. The
    solution is apparently:

    <<At first, I thought the fork child process creation would
    have to be modified so that the resulting child address
    layout would match that of the parent process created by
    Windows. But there is a better (and easier) way. The
    solution is to make the address layout
    of the initial parent process match the address layout that
    results when fork calls CreateProcess. All that is required
    is the initial msys rxvt.exe or cygwin bash.exe originate
    from a CreateProcess invocation similar to the one used by
    those executables. Rxvt and bash could be modified to
    re-launch themselves using reateProcess.
    But for now, I am using a stand-alone launcher to solve the

    The links are dead now, but I'll email him to ask for these

    And as for earnie's question

    <<Why would you expect a runtime for a 32 bit OS to work on a
    64 bit OS.>>

    Nearly all 32 bit application code works in x64, and right
    now there's at least one very strong incentive to get mingw
    to work in x64: Qt4 Open Source is only for mingw.
    Similarly, some may want to use the mingw python instead of
    the MSVC one.

  • sduplichan

    sduplichan - 2005-07-11

    Logged In: YES

    It seems like the problem is caused by fragmentation of the
    virtual memory space of the 32-bit app. This is surprising,
    because Win64 has more total virtual address space available
    for a 32-bit app than Win32 does. A work-around for the
    problem is to create a new Win32 process to run in. Here are
    teo C programs. The first demonstrates a function that can
    be embedded in your code to dump the current virtual memory
    map. I used it to compare execution in Win32 and Win32. The
    other C program is a work-around utility:


    #include <windows.h>
    #include <stdio.h>


    void dumpVirtualMap (HANDLE handle)
    (MEMORY_BASIC_INFORMATION *) malloc (sizeof info [0]);
    MEMORY_BASIC_INFORMATION previous = {0};
    char *va, *lastBase = NULL;
    int success;

    fprintf (stderr, "pid=%d, stack=%p\n",
    GetCurrentProcessId (), &success);

    for (va = 0; va != (void *) 0xFFFFF000; va += 4096)
    success = VirtualQueryEx (handle, va, info, sizeof
    info [0]);
    if (!success) continue;

    if (info->AllocationBase == previous.AllocationBase
    info->AllocationProtect ==
    previous.AllocationProtect &&
    info->Protect == previous.Protect
    info->State == previous.State
    info->Type == previous.Type) continue;

    previous = *info;

    if (info->State & MEM_FREE && info->Protect &
    PAGE_NOACCESS) continue;
    if (info->BaseAddress != info->AllocationBase) fprintf
    (stderr, " ");
    fprintf (stderr, "%8p-%08p", va, va + info->RegionSize
    - 1);
    if (info->BaseAddress == info->AllocationBase) fprintf
    (stderr, " ");
    if (info->State & MEM_COMMIT ) fprintf
    (stderr, " MEM_COMMIT ");
    if (info->State & MEM_FREE ) fprintf
    (stderr, " MEM_FREE ");
    if (info->State & MEM_RESERVE ) fprintf
    (stderr, " MEM_RESERVE ");
    if (info->Type & MEM_IMAGE ) fprintf
    (stderr, " MEM_IMAGE ");
    if (info->Type & MEM_MAPPED ) fprintf
    (stderr, " MEM_MAPPED ");
    if (info->Type & MEM_PRIVATE ) fprintf
    (stderr, " MEM_PRIVATE ");
    if (info->Protect & PAGE_EXECUTE ) fprintf
    (stderr, " PAGE_EXECUTE");
    if (info->Protect & PAGE_EXECUTE_READ ) fprintf
    (stderr, " PAGE_EXECUTE_READ");
    if (info->Protect & PAGE_EXECUTE_READWRITE) fprintf
    (stderr, " PAGE_EXECUTE_READWRITE");
    if (info->Protect & PAGE_EXECUTE_WRITECOPY) fprintf
    (stderr, " PAGE_EXECUTE_WRITECOPY");
    if (info->Protect & PAGE_NOACCESS ) fprintf
    (stderr, " PAGE_NOACCESS");
    if (info->Protect & PAGE_READONLY ) fprintf
    (stderr, " PAGE_READONLY");
    if (info->Protect & PAGE_READWRITE ) fprintf
    (stderr, " PAGE_READWRITE");
    if (info->Protect & PAGE_WRITECOPY ) fprintf
    (stderr, " PAGE_WRITECOPY");
    if (info->Protect & PAGE_GUARD ) fprintf
    (stderr, " PAGE_GUARD");
    if (info->Protect & PAGE_NOCACHE ) fprintf
    (stderr, " PAGE_NOCACHE");
    //if (info->Protect & PAGE_WRITECOMBINE ) fprintf
    (stderr, " PAGE_WRITECOMBINE");
    fprintf (stderr, "\n");

    if (info->AllocationBase == NULL) continue;
    if (info->AllocationBase != lastBase)
    lastBase = (char *) info->AllocationBase;
    fprintf (stderr, "%8p\n", lastBase);

    fprintf (stderr, "stack %8p\n", &success);
    fprintf (stderr, "malloc %8p\n", info);
    // cp new-msys-1.0.dll /test/msys-1.0.dll


    int main (void)
    dumpVirtualMap (GetCurrentProcess ());
    return 0;


    Here is the work-around utility:

    #include <windows.h>
    #include <stdio.h>
    #include <stdlib.h>

    // createprocess.c - call CreateProcess to start the first
    executable in
    // a cygwin or msys session. Starting the
    first executable
    // this way works around a fork problem
    when running
    // cygwin or msys 32-bit executables from
    // Scott Duplichan 3-13-2004

    int main (int argc, char *argv [])
    STARTUPINFOA startup = {0};
    int success, index;
    size_t commandLineLength;
    char *commandLine;

    // put all the command line arguments in one buffer
    commandLineLength = 2;
    for (index = 1; index < argc; index++)
    commandLineLength += strlen (argv [index]) + 1;

    commandLine = malloc (commandLineLength);
    if (!commandLine)
    fprintf (stderr, "createprocess.c: malloc (%u)
    failed\n", commandLineLength);
    return 0;

    commandLine [0] = '\0';
    for (index = 1; index < argc; index++)
    strcat (commandLine, argv [index]);
    strcat (commandLine, " ");

    // run the executable
    startup.cb = sizeof(startup);
    success = CreateProcess (NULL, commandLine, NULL, NULL,
    FALSE, 0, NULL, NULL, &startup, &info);
    if (!success) fprintf (stderr, "createprocess.c:
    CreateProcess error %Xh\n", GetLastError ());
    free (commandLine);
    return success;

    Here are some notes about using the work-around:

    1) Run MSYS-1.0.9.exe. Install in anywhere\msys.
    2) Run MinGW-3.1.0-1.exe. Install in anywhere\msys\Mingw.
    3) Run msysDTK-1.0.1.exe. Install in anywhere\msys.
    4) Install msysDVLPR-1.0.0-alpha-1.tar.gz in anywhere\msys.
    I used winzip.
    5) Rename
    to hide it.
    6) Install w32api-2.5.tar.gz in anywhere\msys. I used winzip.
    7) Run msysDTK-1.0.1.exe. Install in anywhere\msys.
    8) Edit msys.bat. Early in the file add 'set path=' so that
    nothing existing is in the path.
    9) Win64 only: Put createprocess.exe in anywhere\msys\bin.
    In msys.bat, replace 'start rxvt' with 'createprocess
    rxvt' to fix fork problem.
    10) Enlarge the console with options:
    createprocess rxvt -backspacekey  -sl 2500 -fg
    %FGCOLOR% -bg %BGCOLOR% -sr -fn Courier-20 -geometry 90x40
    -tn msys -e /bin/sh --login -i
    11) Send msys.bat to desktop for an mingw box. Fix the icon.
    12) Send msys.bat to desktop for an msys box. Add MSYS to
    msys.bat command line. Fix the icon.
    13) Start the msys box with the desktop shortcut.
    14) cd / && tar -jxf
    15) cd msys/1.0/10/rt && mkdir bld && cd bld
    16) ../src/configure --prefix=/usr
    17) make


  • colourles

    colourles - 2006-09-02

    Logged In: YES

    This problem can be fixed really easily without any 'code'
    being written if you just use the 32bit CMD in the syswow64
    dir to execute the bat file.

    I change the shortcut in the start menu to this to fix the
    %WINDIR%\syswow64\cmd.exe /c T:\msys\1.0\msys.bat

    However a better solution would be to edit msys.bat and
    similar to the 'command' code reload the bat file with the
    32bit cmd if x64 is detected, which is easy enough by
    detecting the presence of the env var "ProgramFiles(x86)".

    So I put the following into msys.bat below the
    'if "%1" == "GOTO:" goto %2' line:

    rem detect 64 Bit windows
    if NOT "x%ProgramFiles(x86)%" == "x" goto _WindowsX64

    then between the ':_Windows' and ':_Resume' sections I added
    the following:

    rem Execute in 32 bit CMD for Windows x64 to get around fork
    set COMSPEC=%WINDIR%\syswow64\cmd.exe
    start %COMSPEC% /s /c "%0 GOTO: _Resume %0 %1 %2 %3 %4 %5 %6
    %7 %8 %9"
    goto EOF

    So the whole file looks like this (removing the changelog):

    @echo off
    rem Copyright (C): 2001, 2002 Earnie Boyd
    rem mailto:earnie@users.sf.net
    rem This file is part of Minimal SYStem
    rem http://www.mingw.org/msys.shtml
    rem File: msys.bat
    rem Revision: 2.0
    rem Revision Date: April 17th, 2002

    rem ember to set the "Start in:" field of the shortcut.
    rem A value similar to C:\msys\1.0\bin is what the "Start
    in:" field needs
    rem to represent.

    rem ember value of GOTO: is used to know recursion has happened.
    if "%1" == "GOTO:" goto %2

    rem detect 64 Bit windows
    if NOT "x%ProgramFiles(x86)%" == "x" goto _WindowsX64

    rem ember command.com only uses the first eight characters
    of the label.
    goto _WindowsNT

    rem ember that we only execute here if we are in command.com.

    if "x%COMSPEC%" == "x" set COMSPEC=command.com
    start %COMSPEC% /e:4096 /c %0 GOTO: _Resume %0 %1 %2 %3 %4
    %5 %6 %7 %8 %9
    goto EOF

    rem Execute in 32 bit CMD for Windows x64 to get around fork
    set COMSPEC=%WINDIR%\syswow64\cmd.exe
    start %COMSPEC% /s /c "%0 GOTO: _Resume %0 %1 %2 %3 %4 %5 %6
    %7 %8 %9"
    goto EOF

    rem ember that we execute here if we recursed.
    for %%F in (1 2 3) do shift

    rem ember that we get here even in command.com.

    if "x%MSYSTEM%" == "x" set MSYSTEM=MINGW32
    if "%1" == "MSYS" set MSYSTEM=MSYS

    if NOT "x%DISPLAY%" == "x" set DISPLAY=

    if EXIST bin\nul cd bin
    if EXIST rxvt.exe goto startrxvt
    if EXIST sh.exe goto startsh

    echo Cannot find the rxvt.exe or sh.exe binary -- aborting.
    exit 1

    rem If you don't want to use rxvt then rename the file
    rxvt.exe to something
    rem else. Then sh.exe will be used instead.

    rem Setup the default colors for rxvt.
    if "x%MSYSBGCOLOR%" == "x" set MSYSBGCOLOR=White
    if "x%MSYSFGCOLOR%" == "x" set MSYSFGCOLOR=Black
    if "x%MINGW32BGCOLOR%" == "x" set MINGW32BGCOLOR=LightYellow
    if "x%MINGW32FGCOLOR%" == "x" set MINGW32FGCOLOR=Navy

    start rxvt -backspacekey  -sl 2500 -fg %FGCOLOR% -bg
    %BGCOLOR% -sr -fn Courier-12 -tn msys -geometry 80x25 -e
    /bin/sh --login -i

    start sh --login -i


  • Earnie Boyd

    Earnie Boyd - 2013-02-14

    Ticket moved from /p/mingw/feature-requests/25/

  • Earnie Boyd

    Earnie Boyd - 2013-02-14
    • labels: MSYS -->
    • status: open --> closed
    • milestone: Waiting_for_Patch_Set --> MSYS
    • type: --> Feature
    • resolution: --> out-of-date
    • category: --> Unknown
    • patch_attached: --> False

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks