I have run into a core and cannot get the traceback from it. I have two questions.
Can I find out the line which causes the crash or where the crash occurred from the
list command output?
How to deal with it otherwise. What should I set heuristic-fence-post to to get some
meaningful data. I tried setting it to 0 but no luck.
(gdb) bt
0 0x00e67a24 in ?? ()
warning: GDB can't find the start of the function at 0xe67a24.
GDB is unable to find the start of the function at 0xe67a24
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0xe67a24 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
(gdb)
A workaround that often works when I see this problem is the command:
x/100a $sp
This will dump the stack with symbols and it's likely that at recent parts of the backtrace will be there. It still won't find the actual current stackframe, but should find the most recent ones with symbols.
Depending upon the target architecture, $sp may need to be something else - whatever register is the stack pointer.
The most common case for me to see gdb fail to find the call stack is for a crash in OpenGL drivers which do not use the expected ARM ABI calling conventions.
I ran into this same error and it turned out to be a symptom of a different problem: I didn't provide a file to gdb, which therefore couldn't build a symbol table. Starting it via gdb filename instead of just gdb fixed this as well.
Related
Can anyone help we out to see the Call Trace in the Trace 32 debugger. I remember such option is available in UDE debugger. Is such option available in the Trace32 as well.
Example:-When a interrupt has raised then I wanted to know what all function s are called in sequence before reaching my break point(if have a break point in some part of code).
To view the call stack use command Frame.view (or Var.Frame if you have an older copy of TRACE32). From the Menu it is View > Stackframe.
I have a core dump from a user. The main program loads selected plugins via dlopen. The process aborted in the plugin module. The user provided a backtrace that includes the filename of the plugin, and the function it aborted in.
I need to look at data, such as arguments passed to the function. How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?
How do I tell gdb where the plugin was loaded, so it can figure out how to show the source and data?
GDB should do that automatically (the load addresses are contained inside the core).
All you need to do is supply the binaries that match customer's environment exactly. See also this answer.
If the core file is good then it should contain the call stack for the crash. You indicated that the crash occurred in the plugin module and function. By going 'up' the stack, you should be able to see the crash point and the containing function. In general, you should be able to look at the local variables including arguments to the function/method.
In short, just debug it like any other core file. Once the call to dlopen completes successfully, the shared library looks (nearly) the same as others loaded at start up.
If you share the bt, I can give some more definitive pointers.
As Employed Russian noted, you local executable and shared libraries must be bitwise the same as your clients. If the local version is different, it will throw off the mapping that gdb does between the core and the executable. This usually results rubbish but sometimes results in a stack that appears vaguely correct. As a result the programmer spends time chasing false leads. This situation is really aggravating!
Is there a way to do this - not with just getting the last things that were in esp/rsp because when I use that in my program I also get the variables that were there but now there are not here. Thanks!
Use the command backtrace full (or abbreviate to bt full) to get all the local variables from parent frames too.
I am using GDB along with a JTAG device, an Abatron BDI2000, to debug a programs running on a Motorola M68332.
The 68332 does not have any hardware breakpoint registers. It has very primitive debugging features.
The build tools do not generate 'elf' files, so no symbols for GDB to use.
Also the program I'm debugging is running in Flash.
In fact the 68332 has only one debug instruction, ti. ti by itself steps to the next assembly instruction. ti xxx steps until the address xxx is reached. [Yes, this is caveman days, cold hammer and chisel :)]
I am able to use GDB with target remote to connect to the BDI2000 and issue the GDB commands 'nexti'. Due to the limitations of the 68332, 'stepi' is equivalent to 'nexti'.
Single stepping is only command available.
The monitor command 'monitor ti ' states change the program counter to and step.
If one uses a 'monitor' command that changes the registers, then GDB does not know about the command and its register cache become out of sync. I have created GDB functions which have the GDB command 'flushregs' at the end of each of them. This marks the register cache dirty. The GDB command will fetch a new set of registers.
I would like to create a symbol table file for debugging, but have not found any documentation on the GDB symbol file format.
Are there alternatives to what I have setup?
I do have a RAM overlay for the Flash area. Would this allow software breakpoints?
Thanks in advance for any advice.
I found I can use 'convenience' variables as a substitute for symbols, since I'm not using ever symbol in the program all at once.
set $Symbol=(unsigned int*)<address>
Each 'Symbol' is declared a pointer to an unsigned int at an address. One can put these statements in .gdbinit, and add to them over time.
One can then state
break $Symbol
I show a GDB command function that can be passed one of these 'convenience' variables in the question linked below.
How do I write a GDB function to make a comparison to the program counter
I got a crash dump (both mdmp and hdmp) for my application (written in C++) captured using dr. watson.
After analyzing the dumps through windbg, I concluded that the crash had occurred in the catch() itself :)
What I need to know is what exception caused the the failure in the first place i.e. I need that penultimate(last but one th) exception that had occurred.
I know I could get the same by some other ways, but is there a specific command with which we could get the list of errors\exceptions occurring from the dump file.
Thanks.
--Samrat Patil
what i usually do is issue the search command looking for specific CONTEXT flags:
s-d esp l10000 1003f
the search is usually performed with the current value of esp as a starting point.
Once you're lucky you get back a bunch of addresses on stack you can further use as parameters for .cxr. The addresses (if several) can be followed to trace the exception flow.
Once the new context is set, it is usually trivial to see where a particular exception is thrown.
isn't !analyze -v working for you?