Compiling a Qt application in order to get better debuginfos (Linux) - c++

I downloaded FabariaGest source code then to compile it you have to run:
on qt 4 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT4=ON -DWANT_QWT=ON
on qt5 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT5=ON -DWANT_QWTQT5=ON
When it finishes, you run
# make install
Since I get a segmentation fault when I start the software, I tried to run
cd /opt/fabaria_gest
gdb fabaria_gest
run
backtrace
but I only get
[user#localhost fabaria_gest]$ gdb fabaria_gest
GNU gdb (GDB) Fedora 7.9.1-19.fc22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fabaria_gest...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/fabaria_gest/fabaria_gest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 7246.
[New Thread 0x7fffe0798700 (LWP 7244)]
Program received signal SIGSEGV, Segmentation fault.
0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
(gdb) backtrace
#0 0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
#1 0x0000000000502a92 in QtPrivate::RefCount::ref() ()
#2 0x0000000000502e37 in QString::QString(QString const&) ()
#3 0x00000000006b9709 in _ZL13getSystemInfov ()
#4 0x00000000006bc29f in main ()
(gdb)
#0 0x00
What can I do to recompile the software in order to get better debuginfos? Setting set follow-fork-mode in GDB did not help

Using
cmake -DCMAKE_BUILD_TYPE=Debug ...
will instruct cmake to generate debug information, which should make the backtrace easier to read.

Related

Why is CrashDump.exe hanging? How to go about debugging?

I'm using the CrashCatcher/CrashDebug code from https://github.com/adamgreen/CrashDebug.
My platform is an STM32H753 running freertos. I've been able to generate a dump file based on the HexDump.c example in CrashCatcher. So far so good. The problem arises when I try to run arm-none-eabi-gdb.exe and connect it to CrashDebug.exe. I'm running on windows 10 and using the stm32 tool chain. I built CrashDebug.exe locally using mingw. I run the following command line:
C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\bin\arm-none-eabi-gdb.exe "fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf" -ex "set target-charset ASCII" -ex "target remote | /Users/felix/source/Thor/CrashDebug.exe --elf C:\Users\felix\source\Thor\fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf --dump C:\Users\felix\source\Thor\crash.dmp"
This runs gdb but the command interpreter becomes unresponsive and never returns to the gdb prompt. I can not even ctrl-c to break. I have to kill the process. Here is what gdb outputs before the hang.
C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (GNU Tools for STM32 9-2020-q2-update.20201001-1621) 8.3.1.20191211-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf...
Remote debugging using | /Users/felix/source/Thor/CrashDebug.exe --elf C:\Users\felix\source\Thor\fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf --dump C:\Users\felix\source\Thor\crash.dmp
I'd expect the gdb prompt to come back so I can get a stack trace out.
I tried running an instance of the mingw gdb and connecting to the running CrashDebug.exe process and halting it. When I do this I get the following stack trace.
(gdb) symbol-file c:/users/felix/source/Thor/CrashDebug/bins/win32/CrashDebug.exe
Load new symbol table from "c:\users\felix\source\Thor\CrashDebug\bins\win32\CrashDebug.exe"? (y or n) y
Reading symbols from c:\users\felix\source\Thor\CrashDebug\bins\win32\CrashDebug.exe...done.
(gdb) thread apply all bt
Thread 2 (Thread 3240.0x2804):
#0 0x77154d11 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x7718dca9 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0xaa43fb20 in ?? ()
#3 0x7718dc70 in ntdll!DbgUiIssueRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x7556fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#5 0x77147a7e in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6 0x77147a4e in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#7 0x00000000 in ?? ()
Thread 1 (Thread 3240.0xfc4):
#0 0x77152a1c in ntdll!ZwWriteFile () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x7509f32c in WriteFile () from C:\WINDOWS\System32\KernelBase.dll
#2 0x00000134 in ?? ()
#3 0x00000000 in ?? ()
(gdb)
Not very helpful. I'm at a loss as to what to do next. Because of the way CrashDebug is launched I can not breakpoint and step through the code to see what is going wrong. Can anyone advise me as to how to get this working?
This issue has been resolved (very quickly) by the awesome author.
https://github.com/adamgreen/CrashDebug/issues/18

schedBreak(<tick>) gdb debugging function not working

I am trying to create breakpoints and debug gem5 using gdb. I referred to http://www.gem5.org/Debugger_Based_Debugging.
As in the official documentation in the above link, I tried `call schedBreak() but it doesn't work. the following are the full commands:
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreak(10000)
warn: need to stop all queues
(gdb) c
Continuing.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Aug 26 2019 20:59:02
gem5 started Sep 8 2019 15:17:55
gem5 executing on nirmal-cadsl2, pid 30158
command line: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 501393000 because exiting with last active thread context
[Inferior 1 (process 30158) exited normally]
(gdb)
While this other tutorial http://gem5.org/wiki/images/0/0e/ASPLOS2017_gem5_tutorial.pdf (assuming the debug function is not particular to ISA) tells me that the function is actually schedBreakCycle(), it gives me this No symbol "schedBreakCycle" in current context. The full commands shown below.
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreakCycle(10000)
No symbol "schedBreakCycle" in current context.
(gdb)
gem5 version: ea8c435b6c6c092d72047eee50f125f5ae7347c3
gdb version: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Also, if I want to debug ALPHA or ARM full system on my ubuntu 18.04(x86), do I have to use any cross-compiled gdb versions or would native gdb suffice?
The tutorial is correct, you have to pass --debug-break to gem5:
gdb --args gem5.debug --debug-break=1000 ...
and then without breaking at main:
run
call schedBreak(5000)
continue
--debug-break generates a break at time 1000 and makes GDB stop there after main, and from that point, schedBreak does work.
Or alternatively first go to:
tbreak doSimLoop
run
call schedBreak(5000)
continue
schedBreak schedules an event in the event queue, which cannot be ready at main.
The breaks work by raising a signal, which GDB stops at by default.
ALPHA and ARM won't make a difference since schedBreak is a tiny helper to debug the host emulator itself, which is likely an x86 program. To debug the guest code, which is what most people want, see e.g. this tutorial.
Tested gem5 master at e87a293d1ffa6da38ba8fa145e7dc5128138ab77 in an X86 debug build.

gdb of simple hello world program not working as expected on Mac 10.13.6

I was just intending to explore the features of gdb by following:
https://www.youtube.com/watch?v=PorfLSr3DDI&t=212s
While trying to replicate the steps as in the movie above, I got slightly different output:
When I ran
gdb a.out
, I got this:
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 5 user staff 160 May 8 22:46 .
This is free software: you are free to change and redistribute it.wxr-xr-x 1 user staff 8432 May 8 22:46 a.out
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.world.c
This GDB was configured as "x86_64-apple-darwin17.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
Users-MBP:codecompre_tooltest user$
For help, type "help".ooltest user$
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
warning: dsym file UUID doesn't match the one in /Users/user/Documents/codecompre_tooltest/a.out
(no debugging symbols found)...done.
(gdb) start
Temporary breakpoint 1 at 0x100000f04
Starting program: /Users/user/Documents/codecompre_tooltest/a.out
[New Thread 0x1703 of process 1645]
[New Thread 0x1903 of process 1645]
[New Thread 0x1a03 of process 1645]
[3]+ Stopped gdb a.out
Why is this so, and how can I solve this?
NOTE: I have followed all the steps in:
http://panks.me/posts/2013/11/install-gdb-on-os-x-mavericks-from-source/
https://gist.github.com/kpy3/27014703672ad6d54c00dfc06e45f1ae

Large core dump with no function names in GDB

I'm fairly new to debugging core dumps on Linux, and I'm running into a weird issue. Hoping to get some suggestions.
We're getting occasional crashes on our game servers running on AWS Linux boxes. I set up the boxes to generate core dumps. Often, the dumps are around a few hundred MB -- roughly the size of the program in memory. These I'm able to load in gdb and seemingly get a valid backtrace.
But frequently, we're getting dumps that are multiple GB in size. Usually, when I load these core dumps in gdb, there's no usable info in the backtrace.
Here's an example output:
> gdb AAPGOrbis core.3871
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from AAPGOrbis...Reading symbols from <path to>/AAPGOrbis.dbg...done.
done.
[New LWP 3871]
[New LWP 3877]
[New LWP 6557]
[New LWP 3876]
[New LWP 6558]
[New LWP 6559]
warning: Error reading shared library list entry at 0x302e6f732e646165
warning: Error reading shared library list entry at 0x74756d5f64616572
Core was generated by `/opt/aapg/Binaries/Linux/AAPGOrbis aaentry?game=AAGame.AAGamePreGameLobbyDedica'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fed61d001f7 in ?? ()
(gdb) bt full
#0 0x00007fed61d001f7 in ?? ()
No symbol table info available.
#1 0x00007fed61d018e8 in ?? ()
No symbol table info available.
#2 0x0000000000000020 in ?? ()
No symbol table info available.
#3 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)
Any ideas as to what might be causing this? I'm wondering if the size of the core dumps coupled with the lack of valid data is indicative of some really bad memory corruption.
Any insight would be greatly appreciated!
warning: Error reading shared library list entry at 0x302e6f732e646165
warning: Error reading shared library list entry at 0x74756d5f64616572
GDB is attempting to read the list of loaded shared libraries from a clearly bogus address (both of these addresses are ASCII strings ead.so.0read_mut).
The most frequent cause is that you have given GDB the wrong binary: the AAPGOrbis that you give GDB must be exactly the same binary as the one that crashed.
Another possibility is that the shared library list (which is in heap) has indeed been corrupted by the program running amok.

Opening core dump file with different executable but the same sources

I have a coredump file from a colleague's machine.
We both have the same sources for the program and the same third party *.so files (like libmysqlclient18 and several in-house ones).
The problem is that we both compile the software (from the same sources) independently and I want to use his core dump files for inspection with GDB on my machine.
When I try to load the core file and my executable into gdb I get:
user#ubuntu:/mnt/hgfs/share/dir$ gdb prog core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /mnt/hgfs/share/dir/prog...done.
warning: exec file is newer than core file.
[New LWP 4465]
[New LWP 4462]
[New LWP 4464]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./prog'.
Program terminated with signal 11, Segmentation fault.
#0 0x002d3706 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt full
#0 0x002d3706 in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Is this possible for this scenario to work? (I compile the software with debugging symbols enabled, of course)
If not, what are the technical details I'm missing?
I know for sure that it wouldn't be possible if he or I would make modifications to the source, since then the executable would be different, but this is not the case, the third party *.so files and the sources, they all match.
UPDATE:
After installing libc6-dbg as user mkfs suggested in the comments, I get this in gdb:
user#ubuntu:/mnt/hgfs/share/dir$ gdb prog core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /mnt/hgfs/share/dir/prog...done.
warning: exec file is newer than core file.
[New LWP 4465]
[New LWP 4462]
[New LWP 4464]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./prog'.
Program terminated with signal 11, Segmentation fault.
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
2188 vfprintf.c: No such file or directory.
(gdb) bt
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
#1 0x00000000 in ?? ()
(gdb) bt full
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
written = 47
target = <optimized out>
used = -1226838776
#1 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Is this possible for this scenario to work?
Yes, but you need to ensure that the symbol layout of the binary you build on both machines is identical (or at least close enough). This isn't necessarily trivial: things like local username, pathname for sources or installation directory, and hostname sometimes leak into the built object files, and may cause symbol mismatch.
To check whether the binaries are close, run diff <(nm a.out) <(nm b.out) -- there should only be few differences. If you see a lot of differences, your binaries aren't close enough.
I compile the software with debugging symbols enabled, of course
This may be your first mistake: if your coworker builds with -O2, and you build with -g (and implied -O0), the binary is guaranteed to not match.
You need to build with exactly the flags your coworker builds with (but you may add debugging symbols; e.g. if your coworker builds with -O2, you should build with -O2 -g together).
P.S. Note that you also need identical versions of system libraries on the two machines.