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?
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 trying to run the autoecho program that uses boost::asio and boost::fiber. I am using the following:
Ubuntu 16
cmake 3.9.1
boost 1_65_0
That program depends on a local copy of round_robin.hpp, yield.hpp and detail/yield.hpp. I have downloaded all of those and the program builds successfully. When I run the code, I get a segmentation fault at the line in main that does:
io_svc->run();
Does anyone know if I am doing something wrong, or if the code has an error in it?
I received an email from Oliver Kowalke #boost:
unfortunately, some fixes did not permission to merged into 1.65 (no permission because too late) - you could use branch develop (github) or you need to wait till 1.66is released.
So, until boost 1.66 is released, this code will not work unless you want to use the develop branch.
I'm using gcc 4.9.2 & gdb 7.2 in Solaris 10 on sparc. The following was tested after compiling/linking with -g, -ggdb, and -ggdb3.
When I attach to a process:
~ gdb
/snip/
(gdb) attach pid_goes_here
... it is not loading symbolic information. I started with netbeans which starts gdb without specifying the executable name until after the attach occurs, but I've eliminated netbeans as the cause.
I can force it to load the symbol table under netbeans if I do one of the following:
Attach to the process, then in the debugger console do one of the following:
(gdb) detach
(gdb) file /path/to/file
(gdb) attach the_pid_goes_here
or
(gdb) file /path/to/file
(gdb) sharedlibrary .
I want to know if there's a more automatic way I can force this behavior. So far googling has turned up zilch.
I want to know if there's a more automatic way I can force this behavior.
It looks like a bug.
Are you sure that the main executable symbols are loaded? This bug says that attach pid without giving the binary doesn't work on Solaris at all.
In any case, it's supposed to work automatically, so your best bet to make it work better is probably to file a bug, and wait for it to be fixed (or send a patch to fix it yourself :-)
I want to make gdb rpm from gdb.spec file using rpmbuld which I can do without any problem but now in addition to that i want GDB to be complied with symbols so that when gdb is being attached to itself I should know the exact call flow and where exactly its failing.
Reason for doing this exercise is I am creating the application which will internally invoke gdb by calling gdb_init and going down failing with segmentation fault in gdb source code.
The easiest way to prevent stripping debug symbols
in rpm build is to add exit 0 at the end of %install.
The symbols are stripped by commands that are appended
to the %install scriptlet. Adding "exit 0" prevents the
commands from being run.
I don't know how you would to this with rpmbuild, but building gdb is really easy. Just get official source package, unpack it, then configure this way:
CFLAGS="-g3 -O0" path/to/gdb/source/configure --prefix path/to/your/installation/directory
make
make install
O0 is not strictly necessary, but if you want to debug a gdb crash, it will help.
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>