MinGW - Minimalist GNU for Windows

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
>Mingw-msys@...
>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

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/

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

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/

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/

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

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/

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