From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-05-21 19:47:31
|
Hi I am having some problems with some msys executables (compiled with GNU Pascal for msys). The problem happens in some programs, and it doesn't occur in others (I am not quite sure what the difference is between those that are problematic and those that aren't). Anyway, when I run them I get this: "m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x3A0000, m.State 0x10000 d:\gpc\win32\example1.exe: *** Couldn't reserve space for cygwin's heap (0x715B0000 <0xB80000>) in child, Win32 error 487" I have checked on Google, and it seems that this problem also occurs with some Cygwin programs under Windows XP. There have been various suggestions on solving this in Cygwin (all relating to the cygwin- 1.dll). None of them have worked with msys. Is there any reason why this should be happening? This is the output of "uname -a": MSYS_NT-5.1 machine_name 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown unknown Msys Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/ |
From: Earnie B. <ea...@us...> - 2004-05-21 20:30:57
|
Is example1.exe a msys-1.0.dll dependent binary? I've stated before that I'm not really interested in supporting someone else's use of the msys runtime; however, you should check your use of the memory heap. You've exceeded the amount of space allocated for your use. Earnie. Prof A Olowofoyeku (The African Chief) wrote: >Hi > >I am having some problems with some msys executables (compiled with GNU >Pascal for msys). The problem happens in some programs, and it doesn't >occur in others (I am not quite sure what the difference is between >those that are problematic and those that aren't). Anyway, when I run >them I get this: > >"m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x3A0000, >m.State 0x10000 >d:\gpc\win32\example1.exe: *** Couldn't reserve space for cygwin's heap >(0x715B0000 <0xB80000>) in child, Win32 error 487" > >I have checked on Google, and it seems that this problem also occurs >with some Cygwin programs under Windows XP. There have been various >suggestions on solving this in Cygwin (all relating to the cygwin- >1.dll). None of them have worked with msys. Is there any reason why >this should be happening? > >This is the output of "uname -a": >MSYS_NT-5.1 machine_name 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown >unknown Msys > >Thanks. > >Best regards, The Chief >-------- >Prof. Abimbola A. Olowofoyeku (The African Chief) >web: http://www.greatchief.plus.com/ > > > >------------------------------------------------------- >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys > > > > > -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-05-22 07:45:41
|
On 21 May 2004 at 16:30, Earnie Boyd wrote: > Is example1.exe a msys-1.0.dll dependent binary? Yes. > I've stated before that I'm not really interested in supporting someone > else's use of the msys runtime; Fair enough - I thought I'd ask anyway, since the same programs, compiled for Mingw and Cygwin, work perfectly fine and don't exhibit this problem. > however, you should check your use of the memory heap. You've > exceeded the amount of space allocated for your use. That is what the Msys system has decided - but the test program does not (at least, it is not supposed to) use much memory at all. Indeed, all it does is to use the functionality of a (Pascal) class library that I am building to create a top-level window that does nothing. I am not sure however how to check my use of the memory heap or how such a trivial program could exceed the allocated heap space (where is the heap space allocated, and how much is allocated?). I am trying to support all Win32 gnu platforms with this class library. I have checked the header flags in the executable for reserved and allocated stack and heap space. These are exactly the same in the Cygwin, Mingw, and Msys executable (as they should be), since the code is exactly the same, and uses the same Winapi calls. So something is amiss somewhere (perhaps in the Msys dll, or the Pascal runtime library). Perhaps I should just stick to testing under Cygwin and Mingw - but it would be a shame to abandon Msys if the problem can easily be solved. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/ |
From: Earnie B. <ea...@us...> - 2004-05-22 10:48:05
|
Prof A Olowofoyeku (The African Chief) wrote: > That is what the Msys system has decided - but the test program does > >not (at least, it is not supposed to) use much memory at all. Indeed, >all it does is to use the functionality of a (Pascal) class library >that I am building to create a top-level window that does nothing. I am >not sure however how to check my use of the memory heap or how such a >trivial program could exceed the allocated heap space (where is the >heap space allocated, and how much is allocated?). > >I am trying to support all Win32 gnu platforms with this class library. >I have checked the header flags in the executable for reserved and >allocated stack and heap space. These are exactly the same in the >Cygwin, Mingw, and Msys executable (as they should be), since the code >is exactly the same, and uses the same Winapi calls. So something is >amiss somewhere (perhaps in the Msys dll, or the Pascal runtime >library). Perhaps I should just stick to testing under Cygwin and Mingw >- but it would be a shame to abandon Msys if the problem can easily be >solved. > > I am willing to help you debug MSYS. 1) cp -a /c/msys/1.0 /c/msys/debug 2) cd msys/build/directory && make clean 3) ccflags='-O0 -g -fnative-struct -DDEBUGGING' OR 3) ccflags='-O0 -g -fnative-struct -DTRACING' OR 3) ccflags='-O0 -g -fnative-struct -DDEBUGGING -DTRACING' 4) make CFLAGS="$ccflags" CXXFLAGS="$ccflags" 5) cp i686-pc-msys/winsup/cygwin/new-msys-1.0.dll /c/msys/debug/bin/msys-1.0.dll Startup the debug version of MSYS and use strace or DbgView to debug it. Caution, all process are slower; use the debug version only for debugging. Caution, comparison to the Cygwin code as it exists today is fruitless. Hint: Copy the desktop icon and modify the properties of the copy to point to the /c/msys/debug/msys.bat and /c/msys/debug/bin directories. I'll be looking forward to a patch. HTH, Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-05-22 13:48:20
|
On 22 May 2004 at 6:48, Earnie Boyd wrote: [...] > > > I am willing to help you debug MSYS. Thanks. I am wondering whether the problem doesn't acutally lie in the startup code. The Cygwin threads I have followed on this topic seem to suggest that cygheap.c might be the place to look, but I will investigate the startup code in the runtime system first. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/ |
From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-05-22 16:06:14
|
On 22 May 2004 at 6:48, Earnie Boyd wrote: [...] > Startup the debug version of MSYS and use strace or DbgView to debug it. > Caution, all process are slower; use the debug version only for > debugging. Caution, comparison to the Cygwin code as it exists today is > fruitless. Hint: Copy the desktop icon and modify the properties of the > copy to point to the /c/msys/debug/msys.bat and /c/msys/debug/bin > directories. > > I'll be looking forward to a patch. Hmmm ... running DbgView shows me zillions of lines of stuff - and there is nothing on any of them that shows me what is wrong. I can't even ascertain which program is producing the lines, since they all seem to be coming from rxvt. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/ |
From: Earnie B. <ea...@us...> - 2004-05-22 17:03:46
|
Prof A Olowofoyeku (The African Chief) wrote: >On 22 May 2004 at 6:48, Earnie Boyd wrote: > >[...] > > >>Startup the debug version of MSYS and use strace or DbgView to debug it. >> Caution, all process are slower; use the debug version only for >>debugging. Caution, comparison to the Cygwin code as it exists today is >>fruitless. Hint: Copy the desktop icon and modify the properties of the >>copy to point to the /c/msys/debug/msys.bat and /c/msys/debug/bin >>directories. >> >>I'll be looking forward to a patch. >> >> > >Hmmm ... running DbgView shows me zillions of lines of stuff - and >there is nothing on any of them that shows me what is wrong. I can't >even ascertain which program is producing the lines, since they all >seem to be coming from rxvt. > > So, set a filter to exclude rxvt from the output. Or use the --norxvt switch to msys.bat (assuming you're using the most recent version of msys.bat). Or set a filter for DbgView to display only the data that may be from cygheap.cc. Lot's of methods. Then there is the gdb method. And there's ``objdump -Sd msys-1.0.dll > /tmp/odmp'' to help as well. Also ``strace -o /tmp/strace.out foo.exe'' may be what the doctor ordered. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Prof A O. (T. A. Chief) <chi...@bi...> - 2004-05-23 20:14:55
|
On 22 May 2004 at 13:03, Earnie Boyd wrote: [...] > So, set a filter to exclude rxvt from the output. Or use the --norxvt > switch to msys.bat (assuming you're using the most recent version of > msys.bat). Or set a filter for DbgView to display only the data that > may be from cygheap.cc. Lot's of methods. Then there is the gdb > method. And there's ``objdump -Sd msys-1.0.dll > /tmp/odmp'' to help as > well. Also ``strace -o /tmp/strace.out foo.exe'' may be what the doctor > ordered. Thanks. I did most of the above with no more illumination. Gdb simply reports that the process terminated with code 01. Strace.out has 0 bytes. Dbgview still has loads of stuff (with "[main] sh ..." or "[sig] sh ..."). There's lots of lines referring to signal.cc, sigproc.cc and malloc.cc, but nothing relating to cygheap.cc. There's also other stuff about "looking for processes to reap", etc., but nothing telling me how the system came to decide that the program is asking for too much heap memory, how much that memory is, and where it happened. I am afraid that the debug messages are probably only intelligble to the person who wrote them in the first place. I suppose it is in malloc.cc that one should be looking, but I am not sure what I am looking for. A series of debug messages in the actual code for example1.exe never get displayed - meaning that the error happened before any code that I wrote ever gets executed. So, I should be looking in the startup code. Any clues? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/ |
From: Earnie B. <ea...@us...> - 2004-05-24 10:29:45
|
Prof A Olowofoyeku (The African Chief) wrote: >On 22 May 2004 at 13:03, Earnie Boyd wrote: > >[...] > > >>So, set a filter to exclude rxvt from the output. Or use the --norxvt >>switch to msys.bat (assuming you're using the most recent version of >>msys.bat). Or set a filter for DbgView to display only the data that >>may be from cygheap.cc. Lot's of methods. Then there is the gdb >>method. And there's ``objdump -Sd msys-1.0.dll > /tmp/odmp'' to help as >>well. Also ``strace -o /tmp/strace.out foo.exe'' may be what the doctor >>ordered. >> >> > >Thanks. I did most of the above with no more illumination. Gdb simply >reports that the process terminated with code 01. > >Strace.out has 0 bytes. > Which strace did you use? Hopefully, one that is msys dependent. >Dbgview still has loads of stuff (with "[main] sh ..." or "[sig] >sh ..."). There's lots of lines referring to signal.cc, sigproc.cc and >malloc.cc, but nothing relating to cygheap.cc. There's also other stuff >about "looking for processes to reap", etc., but nothing telling me how >the system came to decide that the program is asking for too much heap >memory, how much that memory is, and where it happened. I am afraid >that the debug messages are probably only intelligble to the person who >wrote them in the first place. I suppose it is in malloc.cc that one >should be looking, but I am not sure what I am looking for. A series of >debug messages in the actual code for example1.exe never get displayed - > meaning that the error happened before any code that I wrote ever gets >executed. So, I should be looking in the startup code. > > You may have to use the old fashion method of adding your own debug strings. See the win32 API OutputDebugString for starters. >Any clues? Thanks. > > I've followed the malloc issue quite a bit, and yet to come up with a good answer. It is convoluted with some code from newlib and other code from msys source. It is not pretty and it is easy to get lost in the maze. IIRC, there is a MALLOC_DEBUG or some such macro. I've never turned that on so you're on your own if you use it. Good luck, Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |