I need to get the list of shared libraries used by an app in runtime. Most of them can be listed by ldd, but some can be seen only with gdb -p <pid> and by running the gdb command info sharedlib. It would really help, if I could learn in some way: for a chosen library (in the list, output
Tag: gdb
Cleanup output from GDB memory dump
We lost a configuration file which we were able to recover some of the data with a gdb memory dump but many important parts of the file are buried in memory noise. Is there a way to cleanup the dump files? Example output Answer The strings command was able to remove the garbage from the file.
Can’t launch debug – C in VS code on Linux
Let me preface this, I am very new to linux and to working on a non-IDE based setup. I am trying to debug a very simple C program using vs code version 1.55 I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2) I am following the VS code
“add-symbol-file” can’t recognize .bss & .data symbols when using kgdb to debug kernel modules
I am trying to use gdb 8.3.1 for the kernel module on RPI-4 board. When I use the command add-symbol-file to add .bss and .data sections, it doesn’t work. The Kernel version is 5.4 and CONFIG_DEBUG_INFO is turned on. I list the simple code, dmesg and kgdb info below. If you have any idea, please give me some advice. Module
How to get the gdb call stack trace?
I have a core dump and a file where debug information is stored, can I use gdb without using an executable file to get a call stack with the name of functions and lines? Answer can I use gdb without using an executable file to get a call stack with the name of functions and lines? At least on Linux/x86_64,
How do I update my libthread_db shared library so as to match libpthread shared library?
I am using CentOS. I didn’t set up the server and the environment is quite old. I tried to debug a multithreaded server program and some error showed up. Then I realize that the problem is that the version of libpthread shared library I link doesn’t match the version of libthread_db shared library which gdb uses when debugging. I read
Weird Backtrace After a Call Instruction Targeting Signal Functions
I tried to trace evince-3.28.4 execution using GDB. There is a callq instruction at some point in libdl, which is shown below (i.e., at _dl_lookup_symbol_x+840): When the execution reaches here, the backtrace is as follows: But when I enter ni (to jump to the next assembly instruction), it turns into this: As can be seen, after a simple call and
Why is the pthread_mutex_t struct all zeros in gdb?
What causes pthread_mutex_t struct to be all zeros? Core of a deadlocked ARM test application in a gdb session: Answer pthread_mutex_t is used for all mutex types and some of its members are only used for specific mutex types. owner member is set for at least the following mutex types: PTHREAD_MUTEX_ERRORCHECK_NP PTHREAD_MUTEX_RECURSIVE_NP See glibc implementation of pthread_mutex_trylock for full more
“Python Exception There is no member named _M_dataplus.” when trying to print string
I’m trying to debug a segfault in a homework program and I’ve discovered that my GDB can no longer even print std::strings. How can I fix it? I’m on Ubuntu 18.04 LTS. CLang++ version: GDB version: I’ve writen a small test program called gdbbroke.cpp: I expected print test to output: However it just throws the Python error above. Answer With
why virtual address of LOAD program header and runtime virtual address shown by gdb is different?
I’ve been trying to understand elf file format and on elf format documentation, VirtAddr of LOAD header should be the virtual address of the loaded segment. But gdb memmap shows segments to be loaded at different virt address. gdb memmap Answer VirtAddr of LOAD header should be the virtual address of the loaded segment. This is only true for ELF