Is there a way in OCaml to get the current call stack programatically? By this, I do not mean inside a debugger but as a function call inside the program that will print the current call stack. I imagine this should not be beyond the capabilities of the byte-code interpreter, especially if debug symbols are available.
I came to this question looking for the same thing, here's my solution
Printexc.get_callstack 5 |> Printexc.raw_backtrace_to_string
(Its actually a pretty good way to familiarize yourself with a new code base)
You can also use ocamldebug, with which you can start your code, compiled in bytecode. In this environment, Printexc.get_backtrace () are far more completes.
For native code one can use glibc's backtrace, though it may not print all stack frames correctly.
Unfortunately, the only way to get a backtrace from inside the code is when an exception is raised, you can then use Printexc.get_backtrace (). It won't give you though the names of the functions, just the locations in the code of what is in the stack, and only if OCaml was able to recover them...
Related
I am using gdb to trace a program's execution flow. I am using an open source codebase and using certain library functions for my task. I am interested to know the path the program takes to reach the particular function, where I have placed a breakpoint. Is there a way in gdb to list all the functions called before the breakpoint is reached. I am looking to add a field to a particular data structure and it can be done only if I know in which exact function is the data structure being modified.
I am interested to know the path the program takes to reach the particular function, where I have placed a breakpoint.
This is possible by setting a breakpoint on every function, with something like rbreak ., but is not a viable approach for anything larger than tiny toy programs.
Is there a way in gdb to list all the functions called before the breakpoint is reached.
No.
I am looking to add a field to a particular data structure and it can be done only if I know in which exact function is the data structure being modified.
You are holding it wrong. You are trying to replace code understanding and indexing tool with GDB, but GDB is not such a tool.
Further, knowing all functions that have been called before the breakpoint in no way answers "which exact function(s) modified the structure" -- you get a superset instead. That superset can be 1000 times larger than the set you are interested in.
TL;DR: read the source, use tools that help with code understanding and indexing, and don't try to use GDB as such a tool (you'll fail).
Is it possible to 'peek' at the stack enough to deduce, perhaps by mapping an address to the debug .map file or something, what the calling function is programmatically?
I have a function that is called from a ton of different places, and basically if possible I would like to be able to programmatically log out who called the function so that I can trace the progression of parameter values over time, and be able to connect them back to where they may be going wrong. I could add a parameter so that the caller must provide a user string or something, but I'd like to do something less intrusive if it's possible.
GCC has features for this, such as __builtin_return_address (see http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html). They should be used only for debugging or special testing purposes and not as part of production code.
You can generate MiniDump files using windows API and load them later in the debugger and if symbols are available you should be able to debug the crash and investigate values of variables.
I want to print the code of a function in a DLL.
I loaded the dll, I have the name of the desired function, what's next?
Thank you!
Realistically, next is getting the code. What you have in the DLL is object code -- binary code in the form ready for the processor to execute, not ready to be printed.
You can disassemble what's in the DLL. If you're comfortable working with assembly language, that may be useful, but it's definitely not the original source code (nor probably anything very close to it either). If you want to disassemble it, loading it in your program isn't (usually) a very good starting point. Try opening a VS command line and using dumpbin /disasm yourfile.dll. Be prepared for a lot of output unless the DLL in question is really tiny.
Your only option to retrieve hints about the actual implemented functionality of said function inside the DLL is to reverse engineer whatever the binary representation of assembly happens to be. What this means is that you pretty much have to use a disassembler(IDA Pro, or debugger, e.g. OllyDbg) to translate the opcodes to actual assembly mnemonics and then just work your way through it and try to understand the details of how it functions.
Note, that since it is compiled from C/C++ there is lots and lots of data lost in the process due to optimization and the nature of the process; the resulting assembly can(and probably will) seem cryptic and senseless, but it still does it's job the exact same way as the programmer programmed it in higher level language. It won't be easy. It will take time. You will need luck and nerves. But it IS doable. :)
Nothing. A DLL is compiled binary code; you can't get the source just by downloading it and knowing the name of the function.
If this was a .NET assembly, you might be able to get the source using reflection. However, you mentioned C++, so this is doubtful.
Check out this http://www.cprogramming.com/challenges/solutions/self_print.html and this Program that prints its own code? and this http://en.wikipedia.org/wiki/Quine_%28computing%29
I am not sure if it will do what you want, but i guess it may help you.
What's the best way to implement an exception stack trace?
I found some kind of a solution using uncaught_exception() but it requires to add some code to every function.
I need something working on gcc under linux and windows
I don't think there's a cross-platform way to do it. On windows, look at the StackWalk method; on linux, man backtrace. This will get the information; it's up to you to format it.
I'm not sure that a reliable cross-platform method for unwinding the stack exists.
All the platforms/architectures that I've worked on have offered a way to walk the stack when an exception occurs and match addresses to function names. None of these are portable, but the reporting framework can written to be portable with the actual stack walking code remaining platform-specific (StackWalk on Windows or backtrace on Linux).
You might take a look at the libunwind project. I've never used or looked into this myself, so it may not be what you are looking for.
I implemented some code that generates the current stack trace as a string; take a look at the GetStackTrace() function that starts at line 1220 of this file if you are interested. The function works under Linux, MacOS/X, and Windows (note that I borrowed the Windows implementation from here, and that it takes an incredible amount of code to implement this feature under Windows.... bleah)
Looking for a quick and dirty way to identify the caller of a constructor (or any function for that matter) I am writing macros to help identify memory leaks by dumping the this pointers to OutputDebugString.
Knowing where ctor and dtor was called from would help identify the problem.
tnx
\0
If you're using visual studio you can attach the debugger and rather than having a break-point have a trace-point. You do this by right clicking the break-point and choosing When Hit.... Then select to print a message including the stack trace. This message will be sent to the output pane and you can analyze all calls at your leisure.
The best way I can think of is to run your program in a debugger and put a breakpoint in the constructor. Next, examine the call stack.
If you want to target one specific allocation in one specific class, you can keep an allocation count and see which allocation number doesn't get freed. Run the program again, and break on the right allocation number.
If you need to have the call stack dumped to a log, I know it is possible to generate a stack dump using for example win32 API. A more general approach would be to keep an explicit call stack as a global/thread specific state, for example in an std::vector<std::string>-object. (Use RAII to ensure that every push_back is accompanied by a pop_back)
It seems to be you are on windows (OutputDebugString). So you can use the StackWalk64 api to get the stacktrace.
See the "Printing the stack trace in C++ (MSVC)" question for more details.
There is also a lot of leak detection tool available (BoundsChecker, etc).
There is no quick and dirty way for this, C++ does not offer any portable way of looking into a stack-trace. If you want to search for memory-leaks, I'd recommend looking into valgrind and similar tools, they do a great job. As coding guideline, avoid memory-leaks in the first place by using RAII (always have an owner for a resource).
Using gcc? Why not generate a stack trace?
If you're using Linux then Valgrind does everything you want and more. I find it indispensable when developing in C++.
If you're using g++, you can build your project for coverage. When you run over some sample code, you can then view the coverage of your program using gcov.
This output includes the call tree, and you should be able to see calls to constructors, and the functions that are calling them.
The only downside I can think of is that you will only get output for code that is actually executed, and so you'll need to have good test cases. That being said, performing coverage analysis is well worth it anyway. Finally, I highly recommend that you use lcov to view the results!
Can you manipulate the ctor and dtor? I'm no C++ developer and you should easily see this, but perhaps in this case you could pass i.e. a reference on the caller to the constructor.
You running under Windows? Visual Leak Detector has helped me in the past find memory leaks.
Using RAII helps reduce memory leaks too.
If you are feeling adventurous then you can overload the new and delete functions. Paul Nettle does this in his MMGR.
The advise to use a debugger and the call stack is sound and probably the best solution possible. However if you are without a debugger it will not be much help.
Do you know the calling convention being used for your constructor? If so you can use some inline assembler (provided your compiler supports it) to examine the order of function calls. With std calling, the most common convention for Win32, popping the stack will reveal the pointer to the address to return to after the function has been called (i.e. some place in the calling function). This isn't ideal, but you can then go backwards from that point until you reach an address you know to be the start of a function. The only problem here is that you need to get the addresses for all of your functions to be able to do this... this can be done using a simple trick to get the value of eip into another register right at the top of the function, then moving this value into an array to be checked against later when debugging, something like (intel syntax):
call label
label:
pop eax
mov [address of next array entry], eax
Basically you don't, instead of you save all allocation/deallocation and discover who don´t free objects/areas.
See this answers
Heap corruption under Win32; how to locate?
Good lock.
Thanks everyone for the feedback. putting a break point in the ctor is not an option due to hundreds of calls for new objects in even a short lifecycle of the program.
Tracing macros in the ctor and dtor did the trick.
Visual Leak Detector and Stackwalk64 look very promising
also found AfxDumpStack(AFX_STACK_DUMP_TARGET_ODS); // OutputDebugString
but it is VERY noisy