I'm doing some firmware analysis for an embedded system and I've got a trace of the program counter (for every cycle, I know what the program counter is set to). I've additionally got the elf, map file, and the source code.
I'm wondering if there are any open source tools that would allow me to convert this program counter trace into something like a stack trace. From the map file I can determine which function is executing at any given time, but this doesn't allow me to determine if/where function calls/returns occur.
Related
I'm using IntelliJ IDEA 2021.1 to debug the processing difference between two very similar executions of a Legacy Java6EE app. I want to capture the full call and/or stack trace of an application, maybe a thread dump as well since it may be offloading some work to another thread. I'm trying to test only one difference in parameters to determine why it fails with one more explicit parameter set. I'm primarily concerned with the difference in logic followed and maybe see if the query executions are different.
However, I can't find a resource for this process. I'm only able to find the importation of external traces and thread dumps for comparison in the Analysis tab from the JetBrains forum and guides, but nothing showing how to get the initial trace aside from hitting a breakpoint and exporting that small chunk.
I have an input to a Threshold block, which I have verified is working with a QT GUI number sink.
I want to print the output of the Threshold block to console, preferably using the Message Debug block.
However, the output of the Threshold block is a float stream, which doesn't match the input of the Message Debug block.
Is there a way to convert a float stream into message, or am I going down the wrong hole?
My general aim is: when the input exceeds a certain threshold, print to console. Another program will monitor the console and when there is a print out, this triggers another action. I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
I'm also not sure how to output ONLY when the threshold is exceeded, but one problem at a time.
Yes, but that problem is a blocker: Std output is a shared thing across all things in the GNU Radio process, so you can't generally guarantee exclusivity.
Let's not go down that route!
Instead, use something designed for exactly for this kind of things decades ago in UNIX!
Named pipes. These are FIFOs that you can handle like files.
So, use a file source to write to a FIFO, and pipe that FIFO into your other program.
It's really simple:
mkfifo /path/to/where/you/want/to/named/pipe
add a file sink that writes to /path/to/where/you/want/to/named/pipe
either make your other software open that /path/to/where/you/want/to/named/pipe, or do something like other_program < /path/to/where/you/want/to/named/pipe (that actually makes the standard (==console-equivalent) input of your other program what you write to that file sink)
If there is a problem in the source code, usually a programmer goes through the log manually and tries to identify the problem in the source code.
But is it possible to automate this process? Can we automate the process that would give the potential lines in the source code that was responsible for generating the fault.
So, for example:
If there is some problem in the log file. Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
Thanks!!
It depends on the language you are using.
In Java (and probably other JVM languages) this feature is built-in: Every exception that is thrown has a reference to the stack trace, including class, method and line number of every method involved. All you need to do is something like
exception.printStackTrace();
In C and C++, you can use preprocessor macros like __FUNCTION__ or __LINE__ when throwing an exception or writing a log message, for example:
throw "Error in " + __FUNCTION__ + ", line " + std::to_string(__LINE__);
The macros will be replaced by the current function and the current line.
If you are looking for a method that works with any language and any type of logging, there is no good solution. You could run a tool like grep over all source files, that will try to find matches. However this will only work if the log messages appear as string literals in source code at the position where the message is written. This is unlikely because the messages are likely to contain variable values or constants defined somewhere else.
Assuming we are not talking about (unit) testing, because this is what they do - show you where is the problem exactly.
Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
In my team we had similar discussion and what we've come with is a Top5 most likely issues document (PlayBook). After reading logs every time on failure, we've noticed that in most of the times there is a requiring pattern. So 8 out of 10 cases the issues were following one of those patterns. So it is possible to trace the latest changes (with the help from Git). If your changes are small and frequent - this approach works quite well.
I have a big program to run. Using valgrind it takes hours and hours to run. I heard that there is something where we can call valgrind for a specific function in the program. And rest of program will be executed normally(without valgrind env).
Can anybody help me with this. I tried searching it over internet , May be I am missing the term to search.
It all depends on what tool you're wanting to use. For callgrind (the profiler in valgrind) there is an option --toggle-collect=function to allow you to collect information inside a particular function and all its children.
However if the tool you're interested in is memcheck (for capturing leaks / memory errors) then there is no available command line option.
Googling "valgrind profile specific function only" and go "I feel lucky"
In addition to enabling instrumentation, you must also enable event collection for the parts
of your program you are interested in. By default, event collection is enabled everywhere.
You can limit collection to a specific function by using --toggle-collect=function. This will
toggle the collection state on entering and leaving the specified functions. When this option
is in effect, the default collection state at program start is "off". Only events happening
while running inside of the given function will be collected. Recursive calls of the given
function do not trigger any action.
More here
Whether this is possible I don't know, but it would mighty useful!
I have a process that fails periodically (running in Windows 2000). I then have just one chance to react to it before having to restart it and painfully wait for it to fail again. I didn't write the process so don't have the source to debug. The failure is seemingly random.
With a snapshot of the process I could repeatedly and quickly test reactions to the failure.
I had thought of running inside a VM but this isn't possible in this instance.
EDIT:
#Jon Cage asked:
When you say a snapshot, you mean capturing a process when it's about to fail (including memory, program state etc. etc.) ...and then replaying it's final few seconds repeatedly to see what effect it has on some other component?
This is exactly what I mean!
I think minidump is what you are looking for.
You can also used Userdump:
The User Mode Process Dumper
(userdump) dumps any running Win32
processes memory image (including
system processes such as csrss.exe,
winlogon.exe, services.exe, etc) on
the fly, without attaching a debugger,
or terminating target processes.
Generated dump file can be analyzed or
debugged by using the standard
debugging tools.
This article shows you how to use it.
My best bet is to start the process in a debugger (OllyDbg being my preferred tool).
The process will pause on an exception, and you can try to figure out what happened shortly before that.
This needs some understanding of assembler and does not allow to create a snapshot of the process for later analysis. You would need to write your own debugger for that - it should be theoretically possible.