When I use GDB there are some instances where GDB tells me what line the code broke on and there are some times when it doesn't say anything beyond a generic error that I just don't understand.
Is there any way to see the last line of code that was executed before the program broke? For example, if line 50 causes a seg fault or the program to break, is there a way for GDB to show line 49 automatically?
For example, if line 50 causes a seg fault or the program to break, is there a way for GDB to show line 49 automatically?
When you get SIGSEGV on line 50, GDB will stop. If you use list command, it will show you a window around line 50, which will also include line 49.
Note however, that there is absolutely no guarantee that the last line executed before line 50 was line 49.
You could use list to show lines before you get an error.
If it is a segmentation fault, sometimes you need to find the right frame in frame stack.
you use backtrace or bt to find where the frame you are, then use up and down to move.
A frame in library codes do not contain useful symbol table for GDB to indicate your error and most of bugs are happened inside the code you wrote, not standard library codes.
As soon as you get the right frame, you list the corresponding code before error.
Related
I while ago when I had a crash in Visual Studio it would show me the lines where the code crashed as well as all the lines before that that called the function containing the line on which the code crashed.
Since a few months and a few updates in Visual Studio, it started showing only the line on which the crash happens. For example, my code is crashing and the debugger has opened the header file and is showing the line in there where the code crashed but it is not showing the lines that call the function in that header. Previously it would show the lines that call the function, starting from the main function of the program in which the header is used. And I could easily workout which part of the main program is making a bad call to the function in the header.
Is there a way to have it show me all the lines like before? I've searched everywhere online and cannot find this.
I was able to find how to display the call stack window: while debugging, in the Debug menu, select Windows > Call Stack.
This shows all the function calls down to the line where the crash happens. Solved the cause of the particular crash straight away by the way.
Some debuggers (like pdb) automatically break at your first line of code, then allow you to add breakpoints as needed. I'd really like to have that functionality with gdb. (I need to trace code execution through a huge codebase, and none of my guesses as to where to set a breakpoint have been correct, so the program just runs through to the end.) I've read that you can get similar functionality with gdb's starti command, but gdb takes it a little too literally: it stops on the VERY first line of the program where the linking information is. How can I move past this and actually step into my program? I've tried running the s command, but nothing looks familiar.
Here's a picture of what I see when I run starti.
Use start, not starti. start puts a temporary breakpoint on your main() function and begins executing. It should start at the beginning of your program proper.
I'm running through some assembly code in GDB trying to debug my program and I'd like to see what happens if I ignore an instruction entirely, is there a way to do this? (skip past it to the next line without executing it) without having to edit the source code and comment out the function and then recompile?
is there a way to do this
Sure: jump *0x1234 will jump to instruction at address 0x1234.
skip past it to the next line without executing it
"Next line" and assembly debugging rarely go together. As this answer shows, you can skip a line as well.
I'm coding a little program with Qt on Mac OS and this line appears at the end of each execution, I can't get rid of it, even after browsing Google to find a solution.
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined
The message error is my the line of the execution log, repeated 2 or 3 times. Am-I missing something on closing QOpenGL routine?
I'll be glad to post a few line of code but I don't know which ones could be useful.
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.