Is there a utility that will show me a program's current memory contents? Like a hex dump of the entire memory being used by the program? Thanks.
My utility, Bit Slicer, which runs on 10.6 or later can do this for regular applications.
1) Run the program and select a target process.
2) Go to Tools -> Dump All Memory... This will save all the current readable memory in a directory with a bunch of files each indicating a particular memory region and a file that merges everything as well. These files can then be viewed with a hex editor.
3) There's also the real-time memory viewer in the Memory menu for looking at a particular spot.
Dmalloc - Debug Malloc Library
This program came with OS 10.6 but it seems to have disappeared with OS 10.7 (which has many, many, many ... programming complications). Excluding 10.7 regrets, Dmalloc is wonderful way to examine every memory allocation.
Ah ha...
Mac OS 10.7 provides Menu-Product-Profile. I have not investigated fully used it, however, I recognize the Dmalloc icon within it.
Related
Recently, I've been digging in to JVM heap dumps using Eclipse MAT. I like it, but the one feature that I seem to use the most is the Dominator Tree. Eclipse's example screenshot:
Anyways, I find that a lot of the time, I usually get the most value out of just looking at that table and getting the first few entries. Since the turnaround time for getting this is:
Create Heap Dump (jcmd <pid> GC.heap_dump)
Download/Pull heapdump to a location (MAT isn't installed on our servers)
Run Eclipse MAT's ParseHeapDump.sh tool to build the various trees
Open MAT, click Dominator Tree icon.
Analyze
Is there a way to get this equivalent information off of a running JVM programmatically? I'd like to run some kind of gather_dominators.sh <pid> script on a host and get the Top X Objects from a JVM, but I don't know where to start.
If by "running jvm" You meant - "getting the info without doing stop-world heap-dump" then the obvious answer is: in order to do such thing without "full-scan" - the data needs to be collected throughout system life-time by tapping creation/release of each object and by maintaining the statistics. You could achieve such things by instrumentation or by using a ready-made custom agents (jol/jamm/etc). Note that many GCs are already doing similar work to collect (and print) statistics. IIRC - newer JVMs even keep track of such info within the class-metadata area (so getting statistics is instant).
https://github.com/google/allocation-instrumenter
(google-allocation-instumenter)
http://blog.javabenchmark.org/2013/07/compute-java-object-memory-footprint-at.html (with JAMM)
https://github.com/jbellis/jamm (JAMM src)
In Java, what is the best way to determine the size of an object? (JOL/etc here)
http://www.javaworld.com/article/2074458/core-java/estimating-java-object-sizes-with-instrumentation.html (short DYI guide)
https://www.youtube.com/results?search_query=Understanding+Java+GC
(webCast on how GC traverses objects for similar purposes)
On other hand - if You're fine to grab a heap-dump (which should be fine on any production system with any proper node-redundancy in place, designed for handling unavoidable Sun-JVM stop-world GC pauses), then Jhat, MAT-api, YourKit and Jol are probably Your best friends:
Programmatically analyze java heap dump file
How to analyse the heap dump using jmap in java
It is important to note that currently-existing heap-dump format loses the info about actual sizes of objects, so all tools (MAT/etc) are just trying to GUESS it properly:
http://shipilev.net/blog/2014/heapdump-is-a-lie/ (What Heap Dumps Are Lying To You About, by Aleksey Shipilёv)
HTH :)
I need to retrieve information about a hard disk and am using the statfs function to do so.
When your computer displays free space on the HD, does it use "free blocks" or "free blocks available to unpriveleged user"?
Does statfs work with SSDs?
How would the "path" to the main hard drive be stored? On windows it's generally C:, but I am new to OSX.
The man pages don't seem to provide a very comprehensive look of how statfs works.
Mac OSX Snowleopard using C/Objective-C. Xcode 3.2.6
1) Look at man statfs; the structure returned has both counts available (f_bfree and f_bavail).¹
2) Yes, it works on filesystems, not hard drives, so it doesn't matter what type of hard drive (if any) the filesystem is on.
3) /
¹ In case the first part of the question was not about what statfs returns but what “the computer” displays in general, I guess the answer depends on the program used to display the amount of free space. Compare the two values returned by statfs to those displayed by the program you are interested in.
From what experience I have programming whenever a program has a problem it crashes, whether it is from an unhanded exception or a piece of code that should have been checked for errors, but was not and threw one. What would cause a program to completely freeze a system to the point of requiring a restart.
Edit: Thanks for the answers. As for the language and OS this question was inspired by me playing Fallout and the game freezing twice in an hour causing me to have to restart the xbox, so I am guessing c++.
A million different things. The most common that come to mind are:
Spawning too many threads or processes, which drowns the OS scheduler.
Gobbling too much RAM, which puts the memory manager into page-fault hell.
In a Dotnet/Java type environment its quite difficult to seize a system up, because the Runtime keeps you code at a distance from the OS.
Closer to the metal say C or C++, Assembly etc you have to play fair with the rest of the system - If you dont have it already grab a copy of Petzold and observe/experiment yourself with the amount of 'boilerplate' code to get a single Window running...
Even closer, down at the driver level all sorts of things can happen...
There are number of reasons, being internal or external that leads to deadlocked application, more general case is when something is being asked for by a program but is not given that leads to infinite waiting, the practical example to this is, a program writes some text to a file, but when it is about to open a file for writing, same file is opened by any other application, so the requesting app will wait (freeze in some cases if not coded properly) until it gets exclusive control of the file.
And a critical freeze that leads to restarting the system is when the file which is asked for is something which very important for the OS. However, you may not need to restart the system in order to get it back to normal, unless the program which was frozen is written in a language that produces native binary, i.e. C/C++ to be precise. So if application is written in a language which works with the concept of managed code, like any .NET language, it will not need a system restart to get things back to normal.
page faults, trying to access inaccessible data or memory(acces violation), incompatible data types etc.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.
I've faced to a problem with a PIC Micro controller.
I have a micro-controller programmed by me long time ago and I lost the relevant source code and the schematic diagrams. Now I need to invert the value of a port. I can do this using some NOT gates but it is a big hassle to do so. or alternatively I will need to write the whole program back.
I don't expect to see the code back in PIC C or MikroC. Having an understandable assembly code would be sufficient.
So do anyone has any experience on a good HEX decompiler that I can use for this purpose? Any comments based on your experience? :)
EDIT : Device PIC 16F84A
Decompilation is unlikely to be a practical solution, and it is even less likely that a tool for your specific compiler and instruction set combination even exists.
Disassembly however is straightforward, though whether you will be able to make sense of the resulting code is a different matter since no comments or symbols are preserved in the HEX file; if you have the original object code it may render the disassembly more readable. There are many PIC disassemblers available, just Google it; I can't direct you at any specific one because there are a number of PIC families with different instruction sets, and you did not specify.
A simple approach to disassembly would be to simply load your HEX file into MPLAB and select View->Disassembly Listing, then right-click the windows and select "Output to File". This output may need some massaging for it to be suitable for input to an assembler.
I know this is an old post, but I have recently encountered a similar problem and didn't find a very complete answer online. I lost my MPLAB X IDE project due to hard drive failure, luckily I had already programmed a device with a working version of the code.
Recover the .hex
Follow the steps below to recover the .hex information from a programmed device:
Use MPLAB X IDE and your PIC programmer (I used PICkit3) to read the .hex file from the programmed device:
Start a new project for your device.
In "Project Properties" select your programmer.
Right click on the project folder and select "Set as Main Project".
Click on the arrow next to the "Read Device Memory Main Project" and select "Read Device Memory to File". Reading device memory to .hex file
Disassemble the .hex
You can view the disassembly in MPLAB X IDE, but you cannot edit or save it (or at least I couldn't figure out how to) and it is very cryptic. I found the easiest, no strings attached, disassembler to be the one packaged with gputils, it is called gpdasm. To download and install, visit the gputils page here:
https://gputils.sourceforge.io/
Now open a command prompt and navigate to the folder where your .hex file is located. Generate an assembly source file from the .hex with the following command:
gpdasm -p p16f84a -csno hexfile.hex > asmfile.dis
With the -c -s -n and -o options, this generates quite a good listing which is very near to being able to be assembled as is. Obviously the variable names and labels cannot be recovered, but at least subroutines are identified which makes things a lot easier. Hope this helps someone in the future.
There is a list of PIC disassemblers at the official PICList technical reference.
Many people never use a stand-alone disassembler, but prefer to use the disassembler inside their favorite PIC simulator.
http://piclist.com/techref/microchip/dissassemblers.htm
http://piclist.com/techref/microchip/simulators.htm
You should be able to load the hex file into the MPLAB IDE and view the assembly code from there as well as run it and step through the code in the simulater if I am not mistaken.
You can also use it to read the code from a device if it is not code protected.