I'm getting this:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7580d75 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
Can I know why the seg fault is occuring?
I am currently printing the content of a C++ map in a file when this error occurs. The map size would be in MBs, could that be a problem?
Try installing debugging symbols for libc, they should be available as a package. In ubuntu they can be found in the package libc-dbg. Gdb should produce better output for you then.
Related
I have recently started using std::filesystem, and I have faced an issue that I could not fix. I have a class with a function that periodically iterates over some directories and in case new files are found, it adds its name and size to a map container. But I constantly either received segmentation fault or std::bad_alloc. I therefore wrote a simple test to see if it works out of my relatively large and complex make file project. But I still receive segmentation fault.
I simply get the number of files in a directory this way:
int main(){
const fs::path Path = fs::current_path();
for (const auto& p:fs::directory_iterator(Path)){
count++;
}
return count;
}
the error is somehow connected to path object destructor. The debugger throws the following error:
Program received signal SIGSEGV, Segmentation fault.
0x0000555555556693 in std::vector<std::filesystem::__cxx11::path::_Cmpt, >std::allocatorstd::filesystem::__cxx11::path::_Cmpt >::~vector (this=0x20, >__in_chrg=) at /usr/include/c++/8/bits/stl_vector.h:567
567 std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
Program terminated with signal SIGSEGV, Segmentation fault.
Now, I've seen few posts about g++ issue with filesystem, like this one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050
I use g++ 8.4.0 on an Ubuntu 18.4 machine. I tried in my makefile project to add -lstdc++fs to linker flags, but it did not make a difference.
So the question is what is the root cause of this error? Is it really caused by g++?
thanks in advance for helping!
I am using the g++ compiler to compile my code, and I am reaching a Segmentation Fault after the main method returns. I am unable to get what is causing the fault as GDB returns each frame on the stack in the form: #0 0x00007ffff7007478 in ?? ().
The frame #5 is 0x0000000000000000 in ?? () and I find it interesting that it's at address 0, does that mean anything in particular?
I have updated GDB and my g++ compile flags are: -std=c++11 -g -ggdb -O0
Any ideas? If you need anything more, let me know. Thanks!
0x0000000000000000 in ?? () is likely caused from dereferencing a null pointer.
You have the correct debugging flags enabled, but you aren't looking at the call stack.
Try running the program again through gdb, allow it to crash, and then run bt.
This will give you a back trace. You will be able to find the last described function where the problem was likely to have occurred.
I have a program that is seg faulting and I reproduce in gdb as follows:
$ gdb myprogram
(gdb) run mycmdlineargs
Program received signal SIGSEGV, Segmentation fault.
If I type:
(gdb) list
it shows me the source code line where the seg fault occurs, but I would like to see the disassembly (preferably annotated with source code). What command can I use to do that?
You want the disassemble command.
In this program I'm writing, I've been using freeglut and, generally, it has been working. However, sometimes when there is some issue in the program that often has nothing to do with rendering at all, I get a segfault at glutInit() and no explanation from GDB.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7942409 in glutInit () from /usr/lib/x86_64-linux-gnu/libglut.so.3
Backtrace:
#0 0x00007ffff7942409 in glutInit () from /usr/lib/x86_64-linux-gnu/libglut.so.3
#1 0x0000000000415d4c in initGL () at ../gfx/render.cpp:62
#2 0x00000000004035f3 in main () at battle.cpp:49
Running with rendering disabled produces no errors.
So, I am wondering what I need to do to get more information on these failures. Can I get the backtrace to look inside liblut.so.3?
(As an aside, any recommendations for a more reliable toolkit than freeglut are appreciated.)
Can I get the backtrace to look inside liblut.so.3?
You already have a backtrace that is looking inside libglut.so.3.
You need to either
install debug symbols for it (sudo apt-get install freeglut3-dbg or some such), or
compile libglut.so from source, or
debug at assembly level: x/i $pc, disas, info registers, etc.
I have this output when trying to debug
Program received signal SIGSEGV, Segmentation fault 0x43989029 in
std::string::compare (this=0x88fd430, __str=#0xbfff9060) at
/home/devsw/tmp/objdir/i686-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:253
253 { return memcmp(__s1, __s2, __n); }
Current language: auto; currently c++
Using valgrind I getting this output
==12485== Process terminating with default action of signal 11 (SIGSEGV)
==12485== Bad permissions for mapped region at address 0x0
==12485== at 0x1: (within path_to_my_executable_file/executable_file)
You don't need to use Valgrind, in fact you want to use the GNU DeBugger (GDB).
If you run the application via gdb (gdb path_to_my_executable_file/executable_file) and you've compiled the application with debugging enabled (-g or -ggdb for GNU C/C++ compilers), you can start the application (via run command at the gdb prompt) and once you arrive at the SegFault, do a backtrace (bt) to see what part of your program called std::string::compare which died.
Example (C):
mctaylor#mpc:~/stackoverflow$ gcc -ggdb crash.c -o crash
mctaylor#mpc:~/stackoverflow$ gdb -q ./crash
(gdb) run
Starting program: /home/mctaylor/stackoverflow/crash
Program received signal SIGSEGV, Segmentation fault.
0x00007f78521bdeb1 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00007f78521bdeb1 in memcpy () from /lib/libc.so.6
#1 0x00000000004004ef in main (argc=1, argv=0x7fff3ef4d848) at crash.c:5
(gdb)
So the error I'm interested in is located on crash.c line 5.
Good luck.
Just run the app in the debugger. At one point it will die and you will have a stack trace with the information you want.