I have a Java binary heap dump file. Is there a generic way to find out the command line parameters that were passed in to the program's main() method?
I tend to use Eclipse MAT for working with heap dumps.
If the main thread is still alive then the arguments should be referenced on the heap. You should be able to find it using OQL statement like one mentioned in https://stackoverflow.com/a/3675163/32090
Related
I know this is JVM dependent and every virtual machine would choose to implement it a little bit different yet I want to understand the overall concept.
It has been said that for the Memory Segments that the JVM uses to execute a Java program
Java Stacks
Heap
Method Area
PC Registers
Native Method Stacks
are not necessarily implemented with contiguous memory and may be all actually allocated on some heap memory provided from the OS, this leads me to my question.
JVM's that fully use the JIT mechanism and compiles bytecode methods
into native machinecode methods store these methods somewhere, where
would that be? the execution engine ( that is usually written in C /
C++ ) would have to invoke these JIT compiled functions, yet the kernel shouldn't allow a program to execute code saved on the stack / heap / static memory segment, how could the JVM overcome this?
Another question I have is regarding the Java stacks, when a method ( after JIT compilation ) is executed within the processor it's local variables should be saved within the Java stacks, yet again the Java stacks may be implemented with a non-contiguous memory and perhaps even just some stack data structure allocated on the heap acting as a stack, how and where do the local variables of a method being executed get saved? the kernel shouldn't allow a program to treat a heap allocated memory as a process stack, how does JVM overcome this difficuly as well?
Again, I want to emphasis that I'm asking for an overall concept, I know each JVM would choose to implement this a little bit different...
JVM's that fully use the JIT mechanism and compiles bytecode methods into native machinecode methods store these methods somewhere, where would that be?
It is stored in the "Perm Gen" in Java <= 7 and "meta space" in Java 8. This is another native memory region.
the execution engine ( that is usually written in C / C++ ) would have to invoke these JIT compiled functions, yet the kernel shouldn't allow a program to execute code saved on the stack / heap / static memory segment, how could the JVM overcome this?
The memory region is both writable and executable, though I don't know exactly which system call is required to implement this.
Another question I have is regarding the Java stacks, when a method ( after JIT compilation )
Initially the code is not compiled but it uses the stack in the same way.
is executed within the processor it's local variables should be saved within the Java stacks, yet again the Java stacks may be implemented with a non-contiguous memory
There is a stack per thread which is continuous.
and perhaps even just some stack data structure allocated on the heap acting as a stack, how and where do the local variables of a method being executed get saved?
On the thread stack.
the kernel shouldn't allow a program to treat a heap allocated memory as a process stack, how does JVM overcome this difficuly as well?
It doesn't do this.
I successfully hooked BeginScene/EndScene methods of DirectX9's DeviceEx, in order to override regions on the screen of a graphics application. I did it by overriding the first 'line' of the function pointed by the appropriate vtable entry (42 for EndScene) with an x86 jump command.
The problem is that when I would like to call the original EndScene method, I have to write the original code overriden by the jump. This operation is not thread safe, and the application has two devices used by two threads.
I tried overriding the vtable entry or copying it and override the COM interface pointer to the vtable, neither ways worked. I guess the original function pointer is cached somewhere or was optimized in the compilation.
I thought about copying the whole original method body to another memory block, but two problems I'm afraid of: (1) (the easy one I think) I don't know how to discover the length of the method and (2) I don't know if the function body stores offsets which are relative to the location where the function is in memory.
I'm trying to hook WPF's device, if it can help somehow.
Do anyone know a thread safe way for such hooking?
Answering my own question: It seems that for my purpose (performing another method before or instead of the original one within my own process), 'trampoline' is the answer. Generally it means I need to make another code segment that makes exactly what the overriden assembly commands did.
Because it is not an easy task, using an external library is recommended.
A discussion about this topic:
How to create a trampoline function for hook
I would like to save an objective-c block to a file (or any other storage e.g. FTP server) and later load it from there and execute it.
From the Blocks Programming Guide > Using Blocks > Copying Blocks, I know that blocks can be stored in the heap. Because anything stored there can be modified, I think that it is possible to read and write arbitrary content from/to the heap and treat the data as a block.
My problem is, how do you save a block to a file? I don't even know what its structure is/how many bytes it covers. I highly doubt that doing a sizeof() and then reading/writing as many bytes is sufficient. Please help me in finding a start to read and write blocks to/from memory and to understand how they are composed.
Let's start from this code:
void (^myBlock)(void) = ^{ printf("Hello, I'm a Block\n"); };
printf("block size: %lu\n", sizeof(myBlock));
myBlock();
Output:
block size: 4
Hello, I'm a Block
As you can imagine, if this works, a long list of fascinating concepts could be implemented in iOS. Just to name a few:
Downloading executable code (as a block) from the web on the fly, storing it in the heap, and executing it, thus making dynamically linked libraries possible in iOS. From this idea, many more possibilities spawn which are simply too many to write in here.
Compiling code in-app and execute immediately, thus enabling any kind of natively executed scripting languages in iOS apps.
Manipulating code at runtime on the machine level in iOS. This is an important topic for AI and evolutionary/random algorithms.
A block object can be stored in the heap. But a block object itself, like other objects, does not contain executable code -- it only contains captured variables, some metadata, and a pointer to the underlying function that is executed. Even if you could hypothetically serialize block objects, you could only unserialize them on a system that has implemented the same block, i.e. has the same executable code.
To make an analogy, what you are saying applies equally with a normal Objective-C object -- Objective-C objects exist on the heap, you can serialize many Objective-C objects, and Objective-C objects contain executable "methods" that you can call on them. Does that mean you can "download executable code (as an object) from the web on the fly, storing it in the heap, and call methods on it, thus making dynamically linked libraries possible in iOS."? Of course not. You can only potentially unserialize objects on a system that has the same class.
It is not possible:
when you copy the block on the heap you are copying the address of the block itself, not the code of the block.
Moreover the possibility of run not compiled and signed code is against the concept of sandbox, and it'd open the possibility to run evil code in your app breaking the security.
You could implement a custom language interpreter in your app to run a interpred code, but it would be against the Apple policy and it would be rejected during the review process.
I'm trying to debug my program using Valgrind. I compiled with -g3 -O0 -ggdb. How ever I am unable to see the source code corresponding to the point where Valgrind finds problem. The output just shows the name of the (binary)library.
These addresses are of no interest. They belong to the runtime support code that runs after main and calls destructors of global objects and atexit routines. They do not have any source (that you wrote) associated with them.
You can tell that from their placement between exit and __cxa_finalize in the call stack. No user code could possibly belong there.
Silly question, but do you have the source for that library? If not, and that library wasn't compiled with debugging symbols, valgrind isn't going to decompile the binary and show you source.
Valgrind is complaining about a double free on exit. The line:
Address 0x5980ec0 is 0 bytes inside a block of size 29 free'd
Is pointing you where this memory block was previously freed. Taking into account that this is also in exit I can think of two possible reasons:
Some global and static variables that are been freed (with C++ I've seen this problem when directly assigning two global objects, containing pointers, using default copy constructor. As both pointers refer to same memory address, on exit, this is freed twice).
libslm.so has been loaded by using dlopen, then, on exit, it is closed and can also cause some problems with currently managed memory.
I'm assuming that libslm.so is yours so, I think, in both scenarios is important to know something about lines you marked. Have you checked that the path in the log is the same were you have your libraries with debug information? Is AddrScram linked against these libraries (with same exact path)?
I am using Keil's ARM-MDK 4.11. I have a statically allocated block of memory that is used only at startup. It is used before the scheduler is initialised and due to the way RL-RTX takes control of the heap-management, cannot be dynamically allocated (else subsequent allocations after the scheduler starts cause a hard-fault).
I would like to add this static block as a free-block to the system heap after the scheduler is initialised. It would seem that __Heap_ProvideMemory() might provide the answer, this is called during initialisation to create the initial heap. However that would require knowledge of the heap descriptor address, and I can find no documented method of obtaining that.
Any ideas?
I have raised a support request with ARM/Keil for this, but they are more interested in questioning why I would want to do this, and offering alternative solutions. I am well aware of the alternatives, but in this case if this could be done it would be the cleanest solution.
We use the Rowley Crossworks compiler but had a similar issue - the heap was being set up in the compiler CRT startup code. Unfortunately the SDRAM wasn't initialised till the start of main() and so the heap wasn't set up properly. I worked around it by reinitialising the heap at the start of main(), after the SDRAM was initialised.
I looked at the assembler code that the compiler uses at startup to work out the structure - it wasn't hard. Subsequently I have also obtained the malloc/free source code from Rowley - perhaps you could ask Keil for their version?
One method I've used is to incorporate my own simple heap routines and take over the malloc()/calloc()/free() functions from the library.
The simple, custom heap routines had an interface that allowed adding blocks of memory to the heap.
The drawback to this (at least in my case) was that the custom heap routines were far less sophisticated than the built-in library routines and were probably more prone to fragmentation than the built-in routines. That wasn't a serious issue in that particular application. If you want the capabilities of the built-in library routines, you could probably have your malloc() defer to the built-in heap routines until it returns a failure, then try to allocate from your custom heap.
Another drawback is that I found it much more painful to make sure the custom routines were bug-free than I thought it would be at first glance, even though I wasn't trying to do anything too fancy (just a simple list of free blocks that could be split on allocation and coalesced when freed).
The one benefit to this technique is that it's pretty portable (as long as your custom routines are portable) and doesn't break if the toolchain changes it's internals. The only part that requires porting is taking over the malloc()/free() interface and making sure you get initialized early enough.