Is it possible to break into debugger when the allocated memory of attached-to process becomes bigger than a certain value?
Preferrably using Visual Studio 2005, but other IDE's/debuggers are an option.
There is no direct way to do it. Alternative is to set ordinary breakpoint somewhere inside CRT allocation code, and set it to break when the hit count is multiple of say 2000. You'll get to wanted state quickly enough.
I don't know of any direct way in Visual Studio, but you could use ProcDump to create a crash dump when the Memory commit threshold reaches a certain value (-m option).
You would then need to use WinDbg (part of the Windows debugging tools) to inspect the heap.
Related
I would like to create a minimal Windows executable that does nothing - and is minimal in size.
All I care about is keeping a process entry in the task manager.
On Linux, this is very easy (it only takes 2 assembly instructions to use the pause
syscall). How can I achieve similar results on Windows?
I'm trying to keep the executable size to a minimum, I don't want to have 10kB executable that literally does nothing.
Is there a way to achieve this in assembly? As I mentioned, I'd rather not include huge libraries just to make the process "hang".
As Hans suggests in the comments, Sleep(INFINITE) is probably the simplest non-busy wait. It does however mean you have to kill the process with Task Manager to stop it.
Calling MessageBox followed by ExitProcess is probably less annoying if you need to start/stop this process multiple times.
You can probably get it down to 1 KiB with Visual C++ if you don't use the CRT (WinMainCRTStartup and compile with /Zl and smaller alignment)
You can get it slightly smaller with assembly but it is probably not worth it.
In Visual Studio, is it possible to edit assembly language code while stepping through each statement (so that statements in the program can be modified while the program is running?) It would be useful to modify statements in a program while the program is running (for debugging purposes), but I'm not sure if this is possible yet.
You can modify the source code, but it doesn't get reassembled to produce a new binary during your debugging session. The debugger will tell you the "source no longer matches the code" but you can still step. Your display may be confusing because, well, the source code no longer matches the object code :-} I often add comments to instructions or in blank lines, which gets me the complaint, but you can still single-step and see the right source lines in this special case.
I think you can manually modify the memory containing the instruction you want to patch. I've not ever bothered to do this; its easier to set a breakpoint where I'm at, re-assemble, and then run till the breakpoint.
You can modify all the registers and data memory pretty easily (actually you have to use this to modify the code memory, I think!).
A really useful thing to do is "Set Next Statement" to set the PC back to a somewhat earlier place in the code; you can often then step forward to point of failure, if the registers and memory aren't changed. (put cursor in your source or disassembly window, click on a line, then right-click "Set Next Statement")
I rarely used the netbeans debugger but I have this bug in my program which I'm trying to get to the bottom of. Basically my program searches a binary file (4.5gb) for a seqeunce of bytes and writes it to file. However, the programm always stalls at this specific point in the file when reading near halfway of the file (~2gb). They way I using the debugger if putting a breakpoint and keep "continuing" the debugger until it reaches that point in the file but it's going to take forever to reach the 2gb mark. I'm guessing there's a better way to use the debugger which I'm not aware of. Any suggestions?
Netbeans supports conditional breakpoints. If you add a breakpoint via the menu "Debug / New Breakpoint" (or just hit Ctrl+Shift+F8) you can specify a condition (either how often the breakpoint has to be hit until it execution is halted on this breakpoint or an expression).
You could keep a count of how much data you have processed, and add an if() block which checks whether you are up to the 2GB mark. Put a dummy command inside the if() block, and add a breakpoint on the dummy command; this will only be reached when you have processed sufficient data.
I have to find a button's name in a running process memory in Mac OSX and change it.
Supposing there is a "Test" application where it has a "Hello" button, is there any way to attach to "Test" application and change the "Hello!" button to "Bye!"?
I assume this could be done either using GDB or Xcode. If not, how can I do this?
Edit
Assuming you are really looking for dynamic data (as opposed to what your sample seemed to suggest :)) you could always just work with the debugger commands. This will require you to have a sense of the possible memory range to scan (or you'll simply get useless memory violations):
Use gdb commands, loop constructs and libc functions
# assume 0x1234 is a likely base address, say for the heap
(gdb) set $x=0x1234
(gdb) set $y = strdup("lookforthistext")
(gdb) while(0!=memcmp($x++, $y, 15) && $x<0x4321)
>end
(gdb) p $x
(gdb) x $x
This example scans the region 0x1234...0x4321 for the first match and prints/examines the output address.
You can use similar tricks (strncpy...?) to overwrite the memory if you had access to it.
Of course the program may fail dramatically if you do things like changing the length of a substring.. YMMV).
Consider saving your concocted commands as a script (turn on logging, use .gdbinit or even create gdb functions; sadly I know little about the latter)
Original answer:
You "need to"? I doubt it. Your best bet is to work with the windowing/UI API's of your operating system to retrieve the actual window that display the text and make it display another text (usually by sending it appropriate control messages). You'll need plenty of COW powers (think: root) to pull that off.
To answer the direct question:
Usually, messages like this are constants (static data) and as such are either
present in the data segment
read (memory mapped pages) from resources
Both of which are usually (these days at least) in read-only memory segments (think of sharing of memory mapped pages; this gives the kernel opportunity to share mapped regions of shared binary objects between processes - also it serves the obvious security purposes).
On the upside,
strings myprogram | grep 'Hello"
will tell you whether you can use sed, a hex editor or any other suitable editor to manipulate the binary even before it starts. There are two drawbacks I can think of here:
it is not dynamic (you can't have the text change on the fly)
it may break code signing (meaning the executable might get rejected by the OS because it has been modified).
i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.