I wrote Snake in SDL and now want to port it to Android, which means I had to rewrite parts of it to use SDL2. I replaced the key control and rendering parts and it compiles without any errors. However, when I try to run it it crashes immediately. I ran it with the debugger, but it doesn't give any useful information:
(no debugging symbols found)
Program received signal SIGSEGV,Segmentation fault
In ?? () ()
I set a breakpoint on the first line of the code and it doesn't even reach that before crashing. I am also using SDL_image and SDL_ttf.
Source code:
http://www.mediafire.com/?n0zdd061d343w35
Maybe the error is on the SDL loading, you can not resolve the symbols and get an error.
Related
I am using vim for c++ programming. I have bound the compile command to ctrl+c in vim and I run it in another tmux pane by running ./main.out. My problem is that when my c++ program gives me segmentation fault error, I don't know which line has caused the problem. But when I compiled and ran the program in vscode, it showed me the line that caused the error.
I'm seeking for a way to find out the lines that cause runtime errors like segmentation fault error while running the program's binary file in console.
This is an example output when I do ./main.out:
[1] 24656 segmentation fault (core dumped) ./main.out
When compiling the program, add the -g compiler flag, or even better -ggdb3, which will give you a much prettier output, by adding debugging symbols to the executable. Also, make sure that you compile with the -O0 optimization level.
To actually debug the program, run gdb ./main.out to start the program in a debugging session. If you then run r, gdb will start executing the program, and then stop at the line that gives the segfault.
To figure out how you got to that point, run bt while in the debugging session, and you will get a backtrace, which will show you all the function calls that were made to get to the line of code that crashed.
You can of course do a lot more than this (and you will probably need to, since locating the source of an error is often only the first step). You can use p to print the values of variables, set watchpoints, and many more things. For a while now, gdb even ships with a full fledged python interpreter, so you can even write a python script for your custom debugging needs.
Learning how to use gdb can seem overwhelming at the start, but persevere, and I guarantee the effort will pay off big time :)
Ditto on Adin
Also your code can crash due to a call in which the parameter/s are acceptable but cause the proverbial out of range protection fault from some library somewhere if you don't have those debug versions. If an assembly routine is used inside there, they can do some strange things.
So don't be afraid to add temporary code to help like finding a single call that crashes when 1,000,000 other calls to the same did not.
Is why I like to use a lot of generated randoms if possible to test when you got it fixed.
I am using QtCreator 3.6.1 on Ubuntu 14.04 with gcc as my main compiler.
My Qt project is being built in debug mode. However, whenever I press F5, to try to step into the code by setting break points, my code crashes (since the code is buggy) but instead of stopping at the breakpoint, it shows me assembly output!
Here is a screen shot. The code seems to have crashed at where you see the yellow arrow, but I just don't know where in the source code it is!!!
In fact, I have set my breakpoint at a cout statement as you can see here.
Not even the cout statement is executing. The code seems to be crashing before main is executed. I don't know if this is QtCReator problem or something else. I have added -O0 and -g option
to the QMAKE_CXXFLAGS option just to be sure, that debugging symbols are being added, yet I get this problem.
EDIT:
My stack trace looks like this
Also I am not sure if this helps, but when I run the program through the terminal with LD_DEBUG in front of the program's name, I get a huge amount of output.
The last three lines are
.
.
.
7934: symbol=_ZN11QMetaObject8addGuardEPP7QObject; lookup in file=/usr/lib/x86_64-linux-gnu/libQtGui.so.4 [0]
7934: symbol=_ZN11QMetaObject8addGuardEPP7QObject; lookup in file=/usr/lib/x86_64-linux-gnu/libQtCore.so.4 [0]
7934: binding file /usr/lib/x86_64-linux-gnu/libQtGui.so.4 [0] to /usr/lib/x86_64-linux-gnu/libQtCore.so.4 [0]: normal symbol `_ZN11QMetaObject8addGuardEPP7QObject'
[1] 7934 segmentation fault (core dumped) LD_DEBUG=all ./CGALQT_Fix_MainWindow
for this, your application has to link to debug libraries. To investigate where your app crashes, you don't usually need this because you can see all of your own methods in function stack.
How do I debug a segmentation fault?
Basically this is what happens:
I run my server in background: ./server &
then I run my client: ./client
When I try to login to my server, on correct username and password, everything is okay, but when I type invalid user and password, it results in a segmentation fault.
How do I make the compiler/debugger able to output what error its actually see that causes segmentation core dump.
I know gdb but I try using gdb client but it doesn't seem to work.
A good idea with segmentation faults is to run the program with valgrind for debugging. That way, you'll often get more detailed information about what caused your segmentation fault. For example, it will tell you if you are reading from uninitialized memory.
If you are using g++ first compile your program using the -g option. Then use
gdb name_of_program core
to run gdb on the core dump you get (name_of_program is the name of the executable file you just built with g++).
This link is useful for how to use gdb.
http://www.ibm.com/developerworks/library/l-gdb/
this ads annotations to the code. it's helpful only if you have a lot of function calls and you don't know the call path.
I have c/gtk+ application and GList which filled three elements, when i try to run following code with gdb:
if (g_list_length(mw->img_list) > 0)
printf(">0");
else
printf("<0");
i see:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73c4700 (LWP 7936)]
IA__g_list_length (list=0x6e6920) at glist.c:767
767 glist.c: No such file or directory.
in glist.c
What is it?
Thank you.
This is a crash in glib, probably because you're handing it a bad pointer to a list. The debugger tries to load the source code to show you where it crashed, but can't find it (probably because you just linked to the lib, without even having the source handy).
Use the gdb up command to step upwards in the call stack until you reach your code, and inspect the argument you passed to the g_list_length() function.
Your debugger is trying to find the source code for GList to help you to debug the problem. Typically, you won't have the source installed. You'll need to install debugging packages or source of some kind.
If you are on a Fedora system, debuginfo-install glib2 will do it. On Debian or Ubuntu, there may be a package for this, possibly ending in -dbg?
It looks as though its trying to find something(on your hard disk)that doesn't exist. Is that all of the code?
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
gdb <path to the binary> <path to the core file>
For more details on gdb see GDB: The GNU Project Debugger.
Run it through AppVerifier and cdb.
E.g.
cdb -xd sov -xd av -xd ch <program> <args>