I am a new user of MacOS and when using gdb, in case of segmentation faults, I get error with bt command. I am Using C++11. It does not show either source file or address. The error is like:
(gdb) r horse_instanced.xml
Starting program: /Users/bhdurak/Desktop/Ceng477/hw1_solution/raytracer horse_instanced.xml
[New Thread 0x1403 of process 728]
warning: unhandled dyld version (15)
Thread 2 received signal SIGSEGV, Segmentation fault.
0x00007fffca1102f3 in ?? ()
(gdb) bt f
#0 0x00007fffca1102f3 in ?? ()
No symbol table info available.
#1 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)
I have made search but could not find a result. Is there any solution for this problem? Thank you.
Related
I am trying to debug my c++ programming assignment application using gdb on an Ubuntu server, because it produces segmentation fault.
But the file produces ?? symbols that are unreadable to me when I try bt it gives me.
(gdb) bt
#0 0x00007f141956d277 in ?? ()
#1 0x00007ffc1a866bd0 in ?? ()
#2 0x000055e1f101d5e0 in ?? ()
#3 0x00007ffc1a866db0 in ?? ()
#4 0x000055e1f1433e70 in ?? ()
#5 0x00007ffc1a866bd0 in ?? ()
#6 0x000055e1f10224a9 in ?? ()
#7 0x000055e1f14341f8 in ?? ()
#8 0x00000001f14344d0 in ?? ()
#9 0x0000000000000000 in ?? ()
I was following this link, and it told me to load these symbols
symbol-file /path/to/my/binary
sharedlibrary
The sharedlibrary was found, but the symbol-file path is not there. So,it did change bt command output somehow
(gdb) bt
#0 tcache_get (tc_idx=0) at malloc.c:2943
#1 _GI__libc_malloc (bytes=19) at malloc.c:3050
#2 0x000055e1f10224a9 in ?? ()
#3 0x000055e1f14341f8 in ?? ()
#4 0x00000001f14344d0 in ?? ()
#5 0x0000000000000000 in ?? ()
I still don't understand the bug.
Now, I don't know it's a problem from the GDB for not having this symbol-file or its a compilation problem which I don't know how or that's enough for me to debug, but I was following Debugging a Segmentation Fault and it was much clearer to troubleshoot.
When I search for similar cases, all of them were answered only for their case, not a general solution how to deal with these kinds of error. I also thought of installing or locating that symbol-file but I didn't understand how.
If someone could help me, I need to understand what is my problem and how should I fix it.
Note: core dump is produced in the /tmp not in current application directory
I was following this link, and it told me to load these symbols
Don't follow this link (it's unnecessarily complicated for your use case).
Instead, do this:
gdb /path/to/my/binary
(gdb) run
... GDB will stop when your program encounters SIGSEGV
(gdb) bt # should produce meaningful output now.
I'm debugging a SIGSEGV error on a huge application running on Yocto/ARM64 (iMX8QM).
If I run the application in GDB, I can get the backtrace:
Thread 1 "HmiAppCentral" received signal SIGSEGV, Segmentation fault.
0x0000000000b0a0d0 in kanzi::Node3D::~Node3D() ()
(gdb) bt
#0 0x0000000000b0a0d0 in kanzi::Node3D::~Node3D() ()
#1 0x0000000000cd4e44 in kanzi::Model3D::~Model3D() ()
#2 0x0000000000b09c38 in kanzi::Node3D::removeChild(unsigned long) ()
[...]
Then I export the core dump, quit GDB and restart it:
(gdb) generate-core-file
warning: target file /proc/2279/cmdline contained unexpected null characters
[...]
gdb -c core.2279
Then GDB is not able to print the backtrace anymore:
(gdb) bt full
#0 0x0000000000b0a0d0 in ?? ()
No symbol table info available.
#1 0x0000000000000001 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The address of the first frame is correct (0x0000000000b0a0d0), however GDB is not able to find the function name when reloading the core dump. Any hint?
Just like when the OS creates a core file, the original program executable is not included in the core file itself, and it is this executable that contains the debug information (or allows GDB to find the debug information).
What this means is, if you want to debug with the debug information then you need to provide both the executable and the core file, so something like:
gdb my_program.exe -c core.pid
GDB 7.7 shows more number of backtraces (90) for my core file. It is problem with GDB or core file or stack corruption issue?
(gdb) bt
Python Exception exceptions.ImportError No module named traceback:
#0 0x00007f422fd04c37 in ?? () from /users/jegan/lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000002929 in ?? ()
#2 0x7328203c20746e63 in ?? ()
.......................
......................
#88 0x544143494649544e in ?? ()
#89 0x29295d305b4e4f49 in ?? ()
#90 0x0000000000000000 in ?? ()
(gdb)
GDB 7.7 shows more number of backtraces (90) for my core file.
There are a few likely causes for this:
You didn't invoke GDB correctly, or
You are analysing a core dump on a different host from the one it was produced on (or the same host has had its system libraries updated).
Answer for #1.
Answer for #2.
I have a following problem. I runned a programm which has created several threads.
Gdb outputs the following threads:
(gdb) info thread
Id Target Id Frame
3 LWP 23941 0x00007f5fc327c2d4 in ?? ()
2 LWP 22925 0x00007f5fc327e420 in ?? ()
* 1 LWP 23934 0x00007f5fc2779475 in ?? ()
Backtrace of the 2nd thread looks as follows:
(gdb) thread 2
[Switching to thread 2 (LWP 22925)]
#0 0x00007f5fc327e420 in ?? ()
(gdb) bt
#0 0x00007f5fc327e420 in ?? ()
#1 0x00007f5fb406f300 in ?? ()
#2 0x0000000000439021 in AaSemWait (semPtr=0x7f5fb406f300) at ../bm/testing/unit/src/ccs/AaSem.cpp:97
#3 0x00000000004197d5 in bm_semaphore_base::wait (this=0x7fff75b01db8) at /home/michaelfrysztacki/bm_local_build2/BTS_SC_BM/bm/interface/framework/bm_semaphore.h:174
#4 0x0000000000500e1c in radio::thread_synchroniser::wait (this=0x7fff75b01c00) at /home/michaelfrysztacki/bm_local_build2/BTS_SC_BM/bm/radio/testing/stubs/radio_module_receiver.h:107
#5 0x00000000005034a5 in radio::mt_radio_service::send_messages (this=0x7f5fb406d140) at ../bm/radio/testing/unit/mt_radio_service.cpp:236
#6 0x0000000000503010 in radio::mt_radio_service::simulate_radio_modules (this=0x7f5fb406d140, set_timeoff_test=false) at ../bm/radio/testing/unit/mt_radio_service.cpp:189
#7 0x00000000004fde77 in radio::mt_radio_service_module_test_sending_message_and_receive_from_radio_service_Test::TestBody (this=0x7f5fb406d140) at ../bm/radio/testing/unit/mt_radio_service.cpp:347
#8 0x000000000069cab1 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ()
....
This backtrace satisfies me because I know where the programm stopped.
I am confused about the 1st backtrace:
(gdb) thread 1
[Switching to thread 1 (LWP 23934)]
#0 0x00007f5fc2779475 in ?? ()
(gdb) bt
#0 0x00007f5fc2779475 in ?? ()
#1 0x00007f5fc277c675 in ?? ()
#2 0x0000000000000000 in ?? ()
Perhaps this thread runned into a shared library where I don't have debug symbols and sources and I am ok with it. I want to know where from my programm invoked the shared library method. I cannot determine it with this backtrace. I can download some shared libraries with debuging symbols but how can I know which shared library entered my thread ? Or maybe this is the entry point of starting thread using pthread ? Why is this backtrace so poor ? Lastly I am not entirely sure if this is a shared library how can I get it ?
(gdb) info sharedlibrary
warning: Can't read pathname for load map: Input/output error.
From To Syms Read Shared Object Library
No /lib/x86_64-linux-gnu/librt.so.1
No /lib/x86_64-linux-gnu/libexpat.so.1
No /usr/lib/libboost_thread.so.1.49.0
No /usr/lib/libboost_system.so.1.49.0
No /usr/local/lib/libprotobuf.so.8
No /lib/x86_64-linux-gnu/libpthread.so.0
No /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No /lib/x86_64-linux-gnu/libm.so.6
No /lib/x86_64-linux-gnu/libgcc_s.so.1
No /lib/x86_64-linux-gnu/libc.so.6
No /lib64/ld-linux-x86-64.so.2
the 'info sharedlibrary' command lists the shared libraries where I have no debugging symbols. How can I get the library e.g. /usr/lib/libboost_thread.so.1.49.0 with debuging symbols ( and sources ) ?
Your info shared output shows that GDB did not load symbols for any shared library.
The most likely cause: you have set auto-solib-add off somewhere in your ~/.gdbinit file.
You should be able to fix this with either
(gdb) shared . -- force GDB to read all shared libraries, or
just take out the set auto-solib-add off from wherever it's coming from.
Currently I have a C++ program which crashed every now and then when running. I run it in Dr. Memory, but when it doesn't crash there is no obvious error reported, and when it does drmemory doesn't report anything at all (it just ends). So I debugged it with the shipped GDB in the corresponding MinGW package.
The program is compiled & linked with MinGW gcc 32bit (dwarf2 & sjlj produce similar results), under 64bit Windows 7. The GDB debugger caught a SIGSEGV that caused the program to crash. I made a complete backtrace, but I don't know how to analyze it, for I haven't done it before.
This is where the debugger stopped when the program crashed:
Thread 539 (Thread 5904.0x11b4):
#0 0x00000000 in ?? ()
No symbol table info available.
#1 0x00433f1b in pthread_create_wrapper ()
No symbol table info available.
#2 0x763d1287 in msvcrt!_itow_s () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#3 0x763d1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#4 0x74e5336a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
No symbol table info available.
#5 0x77069f72 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
No symbol table info available.
#6 0x77069f45 in ntdll!RtlInitializeExceptionChain () from C:\Windows\system32\ntdll.dll
No symbol table info available.
#7 0x00000000 in ?? ()
No symbol table info available.
I don't know if I should post other parts of the backtrace; it's very long, because the program is a multi-threaded Qt Gui program.
I guess the #0 00000000 in ?? () is where the program crashed, because in other threads there is always a new thread started after ... -> msvcrt!_endthreadex () -> msvcrt!_itow_s () -> pthread_create_wrapper ().
I've been debugging this for days...it's driving me up the wall. Any help will be greatly appreciated!!
P.S. Please let me know if I should post other parts of the backtrace too. I don't know whether the point GDB stopped is just the point problems popped in a multithreaded program.