I get the following error compiling with make (I have cygwin.dll)
*** Couldn't reserve space for cygwin's heap (0x150000) in child, cygheap, Win32 error 0
0 [main] make 4336 sync_with_child: child 2968(0x120) died before initialization with status code 0x1
308 [main] make 4336 sync_with_child: *** child state waiting for longjmp
How could it be solved?
Thanks
I just ran into this problem and was advised to rebase the msys-1.0.dll which was causing the problem.
Specifically, I used the ReBase.exe tool:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64\ReBase.Exe
which is part of v7.1 (and perhaps other versions) of Microsoft's platform sdk available here.
take a backup of the dll, and then try this command line inside the platform sdk command prompt:
rebase -b 0x30000000 /path/to/msys-1.0.dll
this solved the issue for me.
for interest, my recommended virtual memory settings were set at around 3GB, and the actual allocated virtual memory was at 6GB.
Reboot your system:
Most users complaining about this problem reported it goes away after a reboot. If you are using Windows 7, check the message from BerndP in this thread, it has some tips related to adjusting Virtual Memory settings on Windows.
Might be some software interfering with Cygwin:
This post brings an interesting discussion of random problems with Cygwin. The BLODA list presents a list of applications that are known to cause strange failures and problems in Cygwin.
EDIT:
Windows 8 has not been officially released, so don't expect Cygwin to work on it.
Cygwin can be expected to run on all modern 32 bit versions of Windows This includes, as of the time of writing this, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, as well as the WOW64 32 bit environment on released 64 bit versions of Windows (XP/2003/Vista/2008/7/2008 R2).
I am working with eclipse and am using MinGW + Yagarto on Windows 8. Restarting did nothing.
I solved the issue by expanding my virtual memory, which was originally set to 896Mb and is not at 3000Mb and working fine.
This problem can be resolved by changing the compatibility mode of gcc.exe (or whatever called by make) into Windows Xp (in Properties->compatibility)
However, the script must be executed as administrator to avoid multiple confirmations when calling gcc.exe
Related
I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
I tried to learn "Lena's reversing for newbies", when some trouble arise.
I start Pixtopian Book with ollyDbg, then try to have MessageBox with message about uregistered version.
Then i switch to OllyDbg, stop program executing and press "Alt+F9" for "Back to user mode" which stop the program after it exit from DLL.
But after this program does not work, it's frozen and does not respond to my actions.
If i turn off "Back to user mode" program normally work.
What's the problem? Can i try to use "Back to user mode" in IDA (uses WinDbg) or some other debugger and How i can do this? Can i repair it function in OllyDbg?
P.S. It's like the program stopped and didn't run after use "ALT+F9".
/Sorry for my English, i'm just learning ;-)/
First of all, Ollydbg is meant for 32 bit platform. It means that it will run only on a 32 bit OS and can only debug 32 bit apps.
In x64 Operating Systems (specifically Windows) there is a feature called compatibility mode that lets you run 32 bit apps. The 32 bit code is either run by emulation or natively (when the hardware itself implements the instruction set and then it is called x86-64).
So, when you try to run Ollydbg in a x64 environment it will run, but you will experience problems like the one you are facing. It occurs because Ollydbg is run in an emulation mode. Being a debugger it needs access to the registers and other system structures, which it is denied. What it can see is a virtual image of the system.
So the solution to the problem is using a Virtual Machine.
You would install a 32 bit OS in it and debug the app using Ollydbg. As far as Virtual Machines are concerned, I would recommend VMWare. You can use either the workstation or player version. The latter is free but does not support snapshots.
Other solutions are Virtual Box, Parallels Workstation and Microsoft Virtual PC.
The disadvantages of them are that Virtual Box does not support hardware breakpoints, Parallels Workstation is no longer supported as of 2014 and moreover there you would get a BSOD if you try to single step through FPU instructions. I have not tested Virtual PC though.
Note : Ollydbg does not supports x64 but its author is working on a x64 version.
I just learned how to update changes to the exe file for ollydby v 2.01e.
suppose I wished to change a jl command to a jmp; do this by clicking the executable modules button, choose the file and right click to view the file. then record the changes and save file. The saved file also has a backup in case something goes wrong.
I just did a thorough learning of the pixtopian file. When I downloaded
that tutorial I get the file pixtopian107.exe only. Since it didn't agree with the tutorial I investigated further. That file is an installation file. It produces a regular pixtopian.exe file which is the file you wish to play with.
I also noticed that in running the file it never enters the main module.
this is because of the TLS callback. right now I am trying to learn how
to overcome this which is how i came to this site in the first place.
I am using ollydbg vs2.01e very effectively.
Another thing, in vs 2.01e I am still trying to save changed data. Until I succeed I am recording the changes in the exe files using hex editor.
From my experience I can tell that this functionality won't work on Windows 7.
On Windows 7 64bit --> Won't work at all.
On Windows 7 32bit --> Will work partially, but only when using option "File>Attach" in OllyDbg.
For me, best solution was to use Windows XP 32bit, then it worked fine.
all dos base application experts here is one thread i am creating.
i would like your opinion for this issues
i found one problem in windows xp or any windows system higher to windows 98
i have a dos base application which runs perfect on windows 98 but when i am running it on windows xp or other system it is showing me following error message
16 bit Ms-Dos Subsystem
An application has attemped to directly access the hard disk, which cannot
be supported. This may cause the application to function incorrectly.
Choose close to terminate the application
as i can run it by pressing ignore but want to remove this error message
second thing i found is dos base printing
printing is not working properly
as it prints some part then it pause for some time and then resume printing
so how to solve these problems.
An application has attemped to directly access the hard disk, which cannot be supported.
This error means exactly what it says. Older versions of Windows including 95/98/Me gave DOS programs full control over the system, meaning they could access hardware as they wished -- while this maintained compatibility with older programs, it could also cause the entire OS to crash if this one program did something wrong.
The Windows NT family (including XP and all newer versions) runs DOS programs in an NTVDM (NT virtual DOS machine) which does not have direct access to hardware, and any attempt by programs to access such things will cause the program to be terminated. Of course, you can ignore the error, but your program will likely not work correctly.
I posted this on SuperUser...but I was hoping the pros here at SO might have a good idea about how to fix this as well....
Normally we develop in VS 2005 Pro, but I wanted to give VS 2010 a spin. We have custom build tools based off of GNU make tools that are called when creating an executable.
This is the error that I see whenever I call my external tool:
...\gnu\make.exe): *** couldn't commit memory for cygwin heap, Win32 error 487
The caveat is that it still works perfectly fine in VS2005, as well as being called straight from the command line. Also, my external tool is setup exactly the same as in VS 2005.
Is there some setting somewhere that could cause this error to be thrown?
From problem with heap, win32 error 487 :
Each Cygwin app gets a special heap
area to hold stuff which is inherited
to child processes. Eg. all file
descriptor structures are stored in
that heap area (called the "cygheap").
The cygheap has room for at least 4000
file descriptor structures. But -
that's the clue - it's fixed size. The
cygheap can't grow. It's size is
reserved at the application's start
and it's blocks are commited on
demand.
For some reason your server
application needs all the cygheap
space when running under the described
conditions.
A possible solution might be found in Changing Cygwin's Maximum Memory:
Cygwin's heap is extensible. However,
it does start out at a fixed size and
attempts to extend it may run into
memory which has been previously
allocated by Windows. In some cases,
this problem can be solved by adding
an entry in the either the
HKEY_LOCAL_MACHINE (to change the
limit for all users) or
HKEY_CURRENT_USER (for just the
current user) section of the registry.
Add the DWORD value heap_chunk_in_mb
and set it to the desired memory limit
in decimal MB. It is preferred to do
this in Cygwin using the regtool
program included in the Cygwin
package. (For more information about
regtool or the other Cygwin utilities,
see the section called “Cygwin
Utilities” or use the --help option of
each util.) You should always be
careful when using regtool since
damaging your system registry can
result in an unusable system. This
example sets memory limit to 1024 MB:
regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1024
regtool -v list /HKLM/Software/Cygwin
Exit all running Cygwin processes and
restart them. Memory can be allocated
up to the size of the system swap
space minus any the size of any
running processes. The system swap
should be at least as large as the
physically installed RAM and can be
modified under the System category of
the Control Panel.
It wouldn't hurt to ensure that the maximum size of your windows swap file is large enough.
To summerize : The environment doesn't allocate enough heap space for the cygwin executables. For some reason the problem is more acute with VS2010 Express. You need to either fix the environment, or use another Linux port than cygwin, or use Microsoft utilities.
From the cygwin email lists it looks like other people have run into similar situations, even when not running via Visual Studio, to which they've found that the solution is often to play with Cygwin's maximum memory settings:
http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html
(note: it's worth reading this conversation, from above, about some values that did and didn't work).
Others have also reported issues with Anti-Virus software (recommendation is to unload from memory for some reason), and possibly also compatibility settings (try with it set to XP) which can affect cygwin in certain cases. See: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=377066
As for Visual Studio: Are you on a 64bit machine and if so are you usually running the tool in a 64bit environment?
I've found that because Visual Studio 2010 runs in 32bit, tools launched from it are launched as 32bit processes (for a good illustration of this, add "cmd" as a tool). I'm not sure why this wouldn't be affected on 2005 (unless 2005 lets the system launch the process (64bit) and 2010 handles it itself (32bit)).
I have an issue on our Windows 2003 x64 Build Server when invoking shell commands from a script. Each call causes a "memory leak" in the page file so it grows quite rapidly until it reaches the maximum and the machine stops working.
I can reproduce the problem very nicely by running a perl script like
for ($count=1; $count<5000; $count++)
{
system "echo huhu";
}
It is independent of the scripting language as the same happens with lua:
for i=1,5000 do
os.execute("echo huhu")
end
I found somebody describing the same issue with php at
http://www.issociate.de/board/post/454835/Memory_leak_occurs_when_exec%28%29_function_is_used_on_Windows_platform.html
His solution: Firewall/Virus Scanner does not apply, neither are running on the machine.
We can also reproduce the issue on other Developer Machines running XP 64, but not on XP 32 Bit.
I also found an article describing a leak situation in page file at
http://www.programfragment.com/
The guilty guy for the allocation is C:\WINDOWS\System32\svchost.exe -k netsvcs which runs all the basic Windows services.
Does anybody know the issue and how to resolve it ?
We found the issue by reinstalling a similar step by step. It seemed to be caused by a bug in a hardlock driver. After installing a newer version of the driver the issue disappeared.