#281 Make crashes

closed-fixed
MSYS (75)
2003-02-11
2003-02-10
No

Hi

I am working on the MinGW port of ACE/TAO (see
www.cs.wustl.edu/~schmidt). I have a MingW build
running but a few days the make keeps crashing.
Hereby the stack dump.

Johnny

Exception: STATUS_ACCESS_VIOLATION at
eip=71098111
eax=00000000 ebx=00000000 ecx=00000268
edx=00000000 esi=0A1C7EE8 edi=0A1C7C80
ebp=0022D364 esp=0022D33C program=C:\MSYS\1.0
\BIN\make.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame Function Args
0022D364 71098111 (710A4020, 0A1C7DD8,
0A0AB3A8, 0A075398)
0022D384 710308B5 (0A1C7DD8, 7109BF30,
0022D28C, 0022D1AC)
0022D3A4 71030728 (0A1C7DD8, 0A198658,
0022D444, 7109B9CA)
0022D444 7109BA05 (0A1C7DD8, 0A1C7DD8,
0000000E, 7106182E)
0022E814 71061C02 (00000000, 0022E8C4,
0A197528, 0A05A830)
0022E854 71063617 (00000000, 00000003,
0022E8C4, 0A197528)
0022E884 71010AC9 (0022E8C4, 0A197528,
0022ECC4, 7108D0CB)
0022ECC4 7108D0D8 (0A04A3C8, 0A197528,
0022ECF4, 0040CB77)
0022ECF4 0040CB89 (0A197528, 0A05A830,
00425440, C0996B18)
0022ED24 0040D7C0 (00000000, 00000001,
0A197528, 0A05A830)
0022ED84 0040C37A (0A0F3BC8, 71097387,
0022EDC4, 00404647)
0022EDC4 0040C51E (0A0F3BC8, 0A07D2C8,
0022EE14, 0040C69F)
0022EE14 0040C9A4 (0A07D2C8, 00000000,
00000000, 0041961C)
0022EE44 00402BE1 (0A07D2C8, 00000000,
00000001, 00000000)
0022EE74 00419367 (0A07D2C8, 00000001,
0000560C, 9D924654)
0022EED4 00418993 (0A07D2C8, 00000009,
00000000, 00000000)
End of stack trace (more stack frames may be present)
62831996 [main] make 1468 sig_send: wait for
sig_complete event failed, signal -2, rc 258, Win32 error
0
122868319 [main] make 1468 sig_send: wait for
sig_complete event failed, signal -2, rc 258, Win32 error
0
182914654 [main] make 1468 sig_send: wait for
sig_complete event failed, signal -2, rc 258, Win32 error
0
242940955 [main] make 1468 sig_send: wait for
sig_complete event failed, signal -2, rc 258, Win32 error
0

Discussion

  • Earnie Boyd

    Earnie Boyd - 2003-02-10

    Logged In: YES
    user_id=15438

    What version of MSYS are you using, i.e. what is the output
    of ``uname -a''?

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    MSys version is 1.0.8

     
  • Earnie Boyd

    Earnie Boyd - 2003-02-10

    Logged In: YES
    user_id=15438

    This is resolved in the snapshot for MSYS-1.0.9, see
    http://www.mingw.org/download.shtml for links to the file.

    Earnie.

     
  • Earnie Boyd

    Earnie Boyd - 2003-02-10
    • status: open --> closed-fixed
     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    I have downloaded the version you proposes and this night I
    will run a build with msys 1.0.9

     
  • Johnny Willemsen

    • status: closed-fixed --> open-fixed
     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    I have upgrade to Msys 1.0.9 that I downloaded from the
    page you mentioned. Date 24-01-2003. The problem still
    exists with this make version, so set to open again

     
  • Earnie Boyd

    Earnie Boyd - 2003-02-11

    Logged In: YES
    user_id=15438

    Output of ``uname -a'' would prove that you are using the
    1.0.9 version. Does the stackdump look exactly the same as
    above?

    Earnie.

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    uname -a shows version 1.0.9. Stack dump is the same. I
    have cleaned the system and rerunning the build another
    time for another sanity check. Will be fininshed in about 6
    hours

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    uname -a shows version 1.0.9. Stack dump is the same. I
    have cleaned the system and rerunning the build another
    time for another sanity check. Will be fininshed in about 6
    hours

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    uname -a shows version 1.0.9. Stack dump is the same. I
    have cleaned the system and rerunning the build another
    time for another sanity check. Will be fininshed in about 6
    hours

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    I have rerun the build and I have now other errors. See
    http://doc.ece.uci.edu/scoreboard/Win2K_MingW_GCC_3_2/
    2003_02_11_14_02_Brief.html#section_4

    The errors are: couldn't commit memory for cygwin heap.
    win32 error 487. Sounds strange. Cygwin is on the system,
    but msys and mingw are first in the path. When running
    which make and which g++ I get the mingw/msys versions

     
  • Earnie Boyd

    Earnie Boyd - 2003-02-11

    Logged In: YES
    user_id=15438

    Not as strange as it sounds, remember that MSYS is a fork of
    Cygwin and all of the text strings have yet to be changed.

    What windows version are you using?

    Does the build continue if you execute make again?

    No, then, does the build continue if you change to the ace
    directory and execute make?

    Earnie.

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    I am running on a Windows 2000 Server box. Build results
    are available at http://doc.ece.uci.edu/scoreboard/. Look for
    the mingw build.

    When I go after the build is ready to the ace directory and do
    a make, then the make continues from the file where it
    crashed earlier.

     
  • Johnny Willemsen

    Logged In: YES
    user_id=585332

    FYI the system has 1Gb physical memory so there is
    memory enough.

     
  • Earnie Boyd

    Earnie Boyd - 2003-02-11
    • status: open-fixed --> closed-fixed
     
  • Earnie Boyd

    Earnie Boyd - 2003-02-11

    Logged In: YES
    user_id=15438

    I know that the malloc routines used by MSYS exhibit some
    occasional anomilies. I plan to take a look at the malloc
    routines and replace them, as Cygwin itself did after I
    forked. I've placed this in closed status as we are now
    discussing a different bug.

    Earnie.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks