I am using this code as a test.
#include <sstream>
#include <iostream>
int main () {
std::stringstream ss;
ss << "This is a test\n";
std::cout << ss.str();
}
I compile with
g++ -O0 -g test.cpp. When I run the program in gdb and stop at a breakpoint on the cout line, trying to print ss or ss.str() fails.
(gdb) p ss
$1 = <incomplete type>
(gdb) p ss.str()
Couldn't find method std::stringstream::str
gdb also gives me a ton of warnings about the debug information for libstdc++ and libc not matching their respective libraries, followed by an additional warning suggesting I install separate debuginfos.
warning: the debug information found in "/usr/lib/debug/usr/lib64/libc-2.17.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib64/libstdc++.so.6.0.19.debug" does not match "/lib64/libstdc++.so.6" (CRC mismatch).
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64
However, these packages are already installed according to rpm -qa. I don't have permissions to attempt to reinstall these or try other suggestions from this similar question.
I also found this question and checked the debug-file-directory that gdb is using.
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".
I am running RHEL7 with the included versions of g++ and gdb.
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
The command debuginfo-install glibc-2.17-260.el7_6.6.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64 will install debugging information for those packages, not the packages themselves.
It seems that a different version of the debugging information has already been installed on the system, so you should be able to request that your system administrator installs matching package versions. (Some companies have policies against installing compilers and debuggers in production, but that does not seem to apply here.)
If you cannot get the correct debuginfo package versions installed on the system, you can download the packages from the Red Hat Customer Portal, copy it to the machine, unpack them using rpm2cpio … | cpio -id, and point GDB to the extracted debugging information. As of this writing, Red Hat does not offer a public symbol server unfortunately.
Note that packages from CentOS will not work even if they have the same name/version/release because they are not binary-identical due to different build environments.
Related
I'm having issues when trying to debug a cross compiled binary on my WSL2 host and only end up with backtraces with addresses in ?? (), any hint's on what to verify and change are welcome!
file mybin shows:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=..., with debug_info, not stripped
The application is started in WSL2 via qemu-i386(based on output from ps)
NOTE: I was wondering a bit about this because in my prev dev env using vm-ware and ubuntu 18.04 i was not seeing qemu-i386 used but did not think more about it based on WSL2 issues regarding 32bit application support referring to qemu and binfmt solving it.
I'm running gdb-multiarch (GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2)
Loading the executable and listing symbols with info functions <a_regex> works fine but when attaching and breaking i get bt's like this (NOTE output below is taken from VSCode with a few logging flags enabled, hence the -exec bt thing for example):
-exec bt
1: (777701) <-1183-interpreter-exec console "bt"
1: (777704) ->~"#0 0x000000000047a4ea in ?? ()\n"
1: (777707) ->~"#1 0x00007ffd2dcdb1c0 in ?? ()\n"
1: (777709) ->~"#2 0x0000000000467efc in ?? ()\n"
1: (777711) ->~"#3 0x0000000000000000 in ?? ()\n"
NOTE: When attaching i get the following warning:
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
setting architecture to i386:x86-64 is accepted by gdb but makes no difference
Setting a breakpoint gives the following error:
1: (40020) ->&"Cannot insert breakpoint 1.\n"
1: (40020) ->&"Cannot access memory at address 0xbce346f\n"
1: (40020) ->&"\n"
1: (40023) ->^error,msg="Command aborted."
UPDATE: SOLVED
Thought installing gcc-multilib solved it but it seems more likely the issue was because of a bug in Docker Desktop which has been fixed in v3.2.2. See description in my own answer below.
The qemu-i386 thing was bugging me so I decided to try compiling a simple .c with -m32 flag to check if it also would trigger being run via qemu, got errors because I was missing gcc-multilib so I installed it.
Started the buildt binary and noticed that it did not run via qemu-i386.
Started my original application again and this time it did also not start via qemu.
Started gdb-multiarch, loaded the bin and attached to the process and now suddenly everything worked fine, got a nice proper backtrace!
We are trying to track down a Conditional jump or move depends on uninitialised value in a C++ project reported by Valgrind. The address provided in the finding is not really helpful because it points to the end of a GCC extended assembly block, and not the actual variable causing the trouble.
According to the Valgrind's Eliminating undefined values with Valgrind, the easy way, we can use VALGRIND_CHECK_MEM_IS_DEFINED or VALGRIND_CHECK_VALUE_IS_DEFINED after including <memcheck.h>. Additionally, those macros or functions are apparently documented in the header file (there is definitely no man page for them).
However, when I include <memcheck.h> or <valgrind/memcheck.h>, it results in:
fatal error: memcheck.h: No such file or directory
Based on Stack Overflow's How do I find which rpm package supplies a file I'm looking for?, I performed a RPM file search, but its returning 0 hits for memcheck.h.
QUESTIONS
The blog article is a bit dated. Does the information still apply?
If the information is accurate, then where do I find memcheck.h?
$ uname -a
Linux localhost.localdomain 4.1.4-200.fc22.x86_64 #1 SMP Tue Aug 4 03:22:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ g++ --version
g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
...
$ valgrind --version
valgrind-3.10.1
You have to install the RPM valgrind-devel which contains memcheck.h.
The *-devel packages are typically located in the "optional" repositories (e.g. rhel-x86_64-server-optional-6 on RHEL 6). Also, you can find the RPM on Google, download it, and install it on its own. With either approach, memcheck.h is typically placed in /usr/include/valgrind once installed.
Another way to dig into uninitialised value error with valgrind is to
use the embedded gdbserver.
You can then put breakpoints in your program, and interactively
check the definedness of various addresses/length using various
memcheck monitor commands such as:
check_memory [addressable|defined] <addr> [<len>]
check that <len> (or 1) bytes at <addr> have the given accessibility
and outputs a description of <addr>
See e.g. http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
for more information
I'm attempting to get the nacl-gdb working with one of the example applications provided with the nacl_sdk. In particular, I'm trying to get it working with the sample hello_tutorial application in the getting_started/part1 folder (the stub code from this tutorial: https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1).
I've tried following the instructions here: https://developers.google.com/native-client/dev/devguide/devcycle/debugging#debugging-with-nacl-gdb
But whenever I connect to the target, gdb prints out the following:
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I can then continue and the application runs, but it it's very helpful without the debugging symbols. Anybody know why this might not be working properly?
I performed the following steps:
Modified the Makefile to build hello_tutorial.pexe without finalizing it, and added the -g flag when compiling, and re-ran make.
Ran pnacl-translate to create the .nexe files from the un-finalized .pexe.
../../toolchain/linux_pnacl/bin/pnacl-translate --allow-llvm-bitcode-input hello_tutorial.pexe -arch x86-64 -o hello_tutorial_x86_64.nexe
Modified the hello_tutorial.nmf to point to the nexe files instead of the pexe file.
Modified index.html to point to "application/x-nacl", instead of "application/x-pnacl"
Started Chrome with the following command:
/opt/google/chrome/chrome --enable-nacl --enable-nacl-debug --no-sandbox --disable-hang-monitor localhost:5103
Start up the debugger from the part1 folder with the following command:
../../toolchain/linux_x86_newlib/bin/x86_64-nacl-gdb
Ran the following commands from within gdb. (Note that it shows "no debugging symbols found" when reading from the nacl_irt_x86_64.nexe - is that a problem?)
(gdb) nacl-irt hello_tutorial_x86_64.nexe
Reading symbols from /home/bender/dev/nacl_sdk/pepper_33/getting_started/part1/hello_tutorial_x86_64.nexe...done.
(gdb) nacl-irt /opt/google/chrome/nacl_irt_x86_64.nexe
Reading symbols from /opt/google/chrome/nacl_irt_x86_64.nexe...(no debugging symbols found)...done.
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I'm running on Linux:
Linux bender-VirtualBox 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Looks like this is working okay if I use pepper_canary instead of pepper_33. Found some info at this link: https://code.google.com/p/nativeclient/issues/detail?id=3739
Before explaining my problem:
My OS is Ubuntu 12.04 LTS 32bits with 4GB RAM.
My IDE is Code::Blocks 12.11(I've had the same problem with 10.05)
I'm using the GNU GCC Compiler with the -g flag and the -std=c++0x flag.
When trying to debug this program:
using namespace std;
#include<iostream>
int main(){
int n=10;
for(int i=1;i<=n;i++){
int ax=i;
while(ax) ax--;
cout<<i;
}
return 0;
}
I can't get anything to happen,if I try the "Run to cursor" command or if I try to use breakpoints. They just get skipped and my program finishes running.
This is what I get in the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding source dir: /home/classius/CodeBlocks/Dr/
Adding file: /home/classius/CodeBlocks/Dr/bin/Release/Dr
Changing directory to: /home/classius/CodeBlocks/Dr/.
Set variable: LD_LIBRARY_PATH=.:
Starting debugger: /usr/bin/gdb -nx -fullname -quiet -args /home/classius/CodeBlocks/Dr/bin/Release/Dr
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
No symbol table is loaded. Use the "file" command.
Temporary breakpoint 2 ("/home/classius/CodeBlocks/Dr/main.cpp:10) pending.
[Inferior 1 (process 13381) exited normally]
Debugger finished with status 0
If anyone wants to suggest a solution that implies using the terminal, please do it in the most noob-orieted terms you can find!
PS: How to add breaklines on stack-overflow when asking a question?(Solved-Thanks!)
Reading symbols from /home/classius/CodeBlocks/Dr/bin/Release/Dr...(no
debugging symbols found)...done.
This means you didn't have the -g option during compilation.
UPDATE:
file /home/classius/CodeBlocks/Dr/bin/Release/Dr
/home/classius/CodeBlocks/Dr/bin/Release/Dr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7da8c5cff4af5082d82eecc3ede59a5920b253a0, stripped
So it's 'stripped', which means -g option was not really used. You may recheck your compiler config or try to build the Debug version?
in settings menu choose debugger then gdb-cdb tab and then reset default
I'm working on RHEL WS 4.5.
I've obtained the glibc source rpm matching this system, opened it to get its contents using rpm2cpio.
Working in that tree, I've created a patch to mtrace.c (i want to add more stack backtrace levels) and incorporated it in the spec file and created a new set of RPMs including the debuginfo rpms.
I installed all of these on a test vm (created from the same RH base image) and can confirm that my changes are included.
But with more complex executions, I crash in mtrace.c ... but gdb can't find the debug information so I don't get line number info and I can't actually debug the failure.
Based on dates, I think I can confirm that the debug information is installed on the test system in /usr/src/debug/glibc-2.3.6/
I tried
sharedlibrary libc*
in gdb and it tells me the symbols are already loaded.
My test includes a locally built python and full symbols are found for python.
My sense is that perhaps glibc isn't being built under rpmbuild with debug enabled. I've reviewed the glibc.spec file and even built with
_enable_debug_packages
defined as 1 which looked like it might influence the result. My review of the configure scripts invoked during the rpmbuild build step didn't give me any hints.
Hmmmm .. just found /usr/lib/debug/lib/libc-2.3.4.so.debug
and /usr/lib/debug/lib/tls/i486/libc-2.3.4.so.debug
but both of these are reported as stripped by the file command.
It appears that you are installing non-matching RPMs:
/usr/src/debug/glibc-2.3.6
just found /usr/lib/debug/lib/libc-2.3.4.so.debug
There are not for the same version; there is no way they came from the same -debuginfo RPM.
both of these are reported as stripped by the file command.
These should not show as stripped. Either they were not built correctly, or your strip is busted.
Also note that you don't actually have to get all of this working to debug your problem. In the RPMBUILD directory, you should be able to find the glibc build directory, with full-debug libc.so.6. Just copy that library into your VM, and you wouldn't have to worry about the debuginfo RPM.
Try verifying that debug info for mtrace.c is indeed present. First see if the separate debug info for GLIBC knows about a compilation unit called mtrace.c:
$ eu-readelf -w /usr/lib/debug/lib64/libc-2.15.so.debug > t
$ grep mtrace t
name (strp) "mtrace.c"
name (strp) "mtrace"
1 0 0 0 mtrace.c
[10480] "mtrace.c"
[104bb] "mtrace"
[5052] symbol: mtrace, CUs: 446
Then see if GDB actually finds the source file from the glibc-debuginfo RPM:
(gdb) set pagination off
(gdb) start # pause your test program right after main()
(gdb) set logging on
Copying output to gdb.txt.
(gdb) info sources
Quit GDB then grep for mtrace in gdb.txt and you should find something like /usr/src/debug/glibc-2.15-a316c1f/malloc/mtrace.c
This works with GDB 7.4. I'm not sure the GDB version shipped with RHEL 4.5 supports all the command used above. Building upstream GDB from source is in fact easier than Python though.
When trying to add strack traces to mtrace, make sure you don't call malloc() directly or indirectly in the GLIBC malloc hooks.