When trying to save anything in Firefox, using “save as” to do so, when the dialog box starts to show up, everything turns gray for a moment and then Firefox freezes permanently. Running firefox on gdb, I receive these error messages: > [Parent 9504, Main Thread] ###!!! ASSERTION: No GSettings schemas are installed on the system: ‘glib assertion’, file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:184 > (firefox:9504): GLib-GIO-ERROR **: No GSettings schemas are installed on the system > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > g_logv (log_domain=0x7ffff1c42238 “GLib-GIO”, log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7fffffff9cd8) at gmessages.c:1046 > 1046 gmessages.c: No such file or directory. Backtrace result: > #0 g_logv (log_domain=0x7ffff1c42238 “GLib-GIO”, log_level=G_LOG_LEVEL_ERROR, format=, args=args@entry=0x7fffffffa708) at gmessages.c:1046 > #1 0x00007ffff0dc9402 in g_log (log_domain=log_domain@entry=0x7ffff1c42238 “GLib-GIO”, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7ffff1c60cf8 “No GSettings schemas are installed on the system”) at gmessages.c:1079 > #2 0x00007ffff1bfe6b2 in g_settings_set_property (object=, prop_id=, value=0x7fffffffa850, pspec=) at gsettings.c:476 > #3 0x00007ffff12d0a79 in object_set_property (nqueue=0x7fffd7efca10, value=, pspec=0x7fffce9a53c0, object=0x7fffdded6900) at gobject.c:1415 > #4 g_object_new_internal (class=class@entry=0x7fffcd59a6d0, params=params@entry=0x7fffffffa980, n_params=n_params@entry=1) at gobject.c:1808 > #5 0x00007ffff12d24fd in g_object_new_valist (object_type=object_type@entry=140736916656768, first_property_name=first_property_name@entry=0x7ffff1c6087f “schema-id”, var_args=var_args@entry=0x7fffffffaac8) at gobject.c:2034 > #6 0x00007ffff12d27b4 in g_object_new (object_type=140736916656768, first_property_name=0x7ffff1c6087f “schema-id”) at gobject.c:1617 > #7 0x00007ffff551174c in ?? () from /arquivos/Gtk±3.14.0/lib/libgtk-3.so.0 > #8 0x00007ffff5513e50 in ?? () from /arquivos/Gtk±3.14.0/lib/libgtk-3.so.0 > #9 0x00007ffff550f744 in ?? () from /arquivos/Gtk±3.14.0/lib/libgtk-3.so.0 > #10 0x00007ffff12cb385 in g_closure_invoke (closure=0x7fffcdb80c60, return_value=0x0, n_param_values=1, param_values=0x7fffffffae60, invocation_hint=0x7fffffffae00) at gclosure.c:768 > #11 0x00007ffff12dd11c in signal_emit_unlocked_R (node=node@entry=0x7fffcc2fc520, detail=detail@entry=0, instance=instance@entry=0x7fffca161fb0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffae60) at gsignal.c:3553 > #12 0x00007ffff12e5d95 in g_signal_emit_valist (instance=instance@entry=0x7fffca161fb0, signal_id=signal_id@entry=291, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffb030) at gsignal.c:3309 > #13 0x00007ffff12e64aa in g_signal_emit_by_name (instance=0x7fffca161fb0, detailed_signal=0x7ffff5717393 “default-size-changed”) at gsignal.c:3405 > #14 0x00007ffff5518c41 in ?? () from /arquivos/Gtk±3.14.0/lib/libgtk-3.so.0 > #15 0x00007ffff12d350b in object_set_property (nqueue=0x7fffcb20e890, value=0x7fffffffb250, pspec=0x7fffcbad19a0, object=0x7fffca161fb0) at gobject.c:1415 > #16 g_object_set_property (object=0x7fffca161fb0, property_name=, value=0x7fffffffb250) at gobject.c:2363 > #17 0x00007ffff12d0add in object_set_property (nqueue=0x7fffcb20e7c0, value=0x7fffffffb2b0, pspec=0x7fffcbad19a0, object=0x7fffcccd0670) at gobject.c:1415 > #18 g_object_new_internal (class=class@entry=0x7fffcf104f00, params=params@entry=0x7fffffffb390, n_params=n_params@entry=2) —Type to continue, or q to quit— at gobject.c:1828 > #19 0x00007ffff12d24fd in g_object_new_valist (object_type=object_type@entry=140736584521760, first_property_name=first_property_name@entry=0x7ffff56fe920 “title”, var_args=var_args@entry=0x7fffffffb4d8) at gobject.c:2034 > #20 0x00007ffff12d27b4 in g_object_new (object_type=140736584521760, first_property_name=0x7ffff56fe920 “title”) at gobject.c:1617 > #21 0x00007ffff550fac5 in gtk_file_chooser_dialog_new () from /arquivos/Gtk±3.14.0/lib/libgtk-3.so.0 > #22 0x00007fffeec71630 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #23 0x00007fffeec70588 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #24 0x00007fffeabcb16e in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #25 0x00007fffeabc97c2 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #26 0x00007fffeabc887b in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #27 0x00007fffeac706c0 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #28 0x00007fffeaba671a in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #29 0x00007fffeb8bf375 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #30 0x00007fffeaba6304 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #31 0x00007fffeb4a8e6c in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #32 0x00007fffeb4a3d7e in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #33 0x00007fffeb4a1c95 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #34 0x00007fffec8d0eda in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #35 0x00007fffec527b01 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #36 0x00007fffebe31fa9 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #37 0x00007fffebdf20d7 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #38 0x00007fffebdf1198 in ?? () from /media/34GB/Arquivos-de-Programas-Linux/firefox/libxul.so > #39 0x00007ffff804efa6 in ?? () > #40 0x00007ffff6ddae70 in __libc_start_main (main=0x7ffff804ed00, argc=1, argv=0x7fffffffe2e8, init=, fini=, rtld_fini=, stack_end=0x7fffffffe2d8) at libc-start.c:269 > #41 0x00007ffff8062777 in _start ()

I have built gdb-7.12 with python support in my ubuntu 14.04 and have enabled pretty printing and configured my gdbinit file by following https://sourceware.org/gdb/wiki/STLSupport . But whenever i print the size of any container: p ivec.size() Cannot evaluate function -- may be inlined Here is the MCVE i am using #include using namespace std; int main(){ vector ivec; return 0; } I have tried different compiling options g++-6 -g -O0 -fno-inline-functions -gdwarf-2 Source.cpp --std=c++14 In fact i have tried every combination of the above options, and always the same problem. I tried switching to gdb-7.11 (also built from source) to see if it fixes the problem and also switched to g++-4.8, none of them seem to fix the issue. What am i doing wrong? Is there some specific order in which you have to give the options? Is there a way to check if the -O0 option is working?

I have core dump file and gdb. I can do gdb (gdb)bt This will give me backtrace but I want to do this using a shell script and in non-interactive mode. Writing

gdb exe core

takes me to gdb CLI and needs manual intervention. Any idea how can I automate it?

I had purchased two Fluke Etherscopes, these are stuck with the message 'Loading Kernel' on the screen. I was able to get a serial console, and access the bootloader using the serial port on the side of the device. I can access the bootloader (Intrinsyc Bootloader) and have tried to use the update files to install a new kernel. It installs successfully to the flash memory, and then tries to boot. I have tried to pass kernel boot parameters through the boot command, and get no output what so ever. I have successfully identified the JTAG pins, except for the nTRST pin, pretty sure I know which pin, but showing a diode between the pad and the suspected pin. I have flashed the Black Magic Probe firmware and bootloader to my STM32F104 development board, it has a logic level of 3.3v, and so does the CPU. I know which pins to attach the BMP to, but I am not sure where to go from here. I have tried looking for information on debugging the Linux kernel through JTAG, and GDB, but nothing that I see as very clear. I found multiple firmware update files for this device, and also found some source code, both on a public fluke ftp site. I have tried to contact Fluke for service information, and they told me to reach out to NetScout, who say that Fluke never gave them that information. I am attaching the serial printout from when I press the power button to where it stops outputting and just shows the loading kernel screen. I would like to at least get an idea of what I can research in order to get either debug output to the serial console, or debug output through the JTAG port and the BMP firmware. The CPU is the Intel XScale PXA255. I know that when a CF card is inserted with a file with the name 'ZIMAGE', it tries to load it as a 'Debug Kernel' into RAM, and then points to it for execution. If there is anymore information I can give anyone, please let me know. I bought these devices broken so that I can learn while trying to fix them, and would really like to get them up and running. Again, any information I can pass along, please let me know and I will post it. Thank you all for your time. **Serial Output from Boot:**

**************************************************
** Intrinsyc Bootloader (IBoot)                 **
** Copyright 2001,2002 Intrinsyc Software Inc.  **
** Version: 2.0                                 **
** Support: http://www.intrinsyc.com             **
**************************************************
Enabling LCD controller
Setting Registers in the EPSON Controller!!
Finished Setting Registers in the EPSON Controller!!
MCMEM0 : 0x0002449D
MCATT0 : 0x0002449D
MCIO0  : 0x00014290
MECR   : 0x00000000
MCCR : 0x00000001
GPLR0 : CFF79FFD
PCMCIA Detected 0 Slots.
setup def img : Image Offset : 70
Image Size X : 294 Y : 70
img done
Loading TXRX Xilinx.
TXRX Xilinx Complete.
reseting PHY
We Should Auto Negociate
Phy Control Register = 0x0000FFFF
Phy ID Register one = 0x0000FFFF
Phy ID Register two = 0x0000FFFF
Phy STAT Register = 0x0000FFFF
Xilinx TXRX Reg : 0x003C3B3C
Leaving init_ethernet
IBoot> help
boot, bootmem, copy, crc, createfis, decode, download,
eraseflash, exec, flash, flashloader, flashverify, getbyte, getword,
getdword, help, info, jump, memtest, ping, reboot,
save, setbyte, setword, setdword, set, set gw, set hwrev,
set option, set initpwr, set ip, set mac, set mask, set mfgdate, set mfgtest,
set model, set serial, set server, set speed, set trial, show, reflash
IBoot> boot
Board Control Regs : 0x00000042
Loading PCMCIA Xilinx.
Waiting for Xilinx INIT pin low.
Waiting for Xilinx INIT pin high.
Writing data to Xilinx.
Waiting for Done High.
Relocating zImage from 000C0000 to A0008000 (len=00100000)
Proper ARM zImage ID found. Booting...
Uncompressing Linux............................................................... done, booting the kernel.

I have installed QEMU in RHEL for running the assembly programs in ARM. I have successfully installed QEMU and ARM. However, for debugging we are thinking to use GDB. I want to install the **GDB-Multiarch** in RHEL. I have installed GDB and when I run the command **GDB** I am getting the GDB shell successfully. However, I need to use the **GDB-Multiarch** and I am not able to run this command. To successfully run an assembly program, I need to execute the below command. qemu-system-arm -S -s -M versatilepb -daemonize -m 128M -d in_asm,cpu,exec -kernel hello_world.bin ; gdb-multiarch --batch --command=hello_world.gdb In the above command, I am getting the error as gdb-multiarch command as not found. I am really new to this environment and I would appreciate the help.

I am trying to analyze a VMware memory dump from an AlmaLinux guest. I converted the snapshot to a core dump using vmss2core:

vmss2core-sb-8456865.exe -N vSRV1_Snapshot815.vmsn vSRV1_Snapshot815.vmem

Then, I installed the necessary tools for crash dump analysis:

sudo dnf install yum-utils -y
sudo dnf install kexec-tools crash gdb -y
sudo dnf debuginfo-install kernel-debuginfo-$(uname -r) -y

However, when I try to analyze the dump with crash, I get an error:

crash /usr/lib/debug/lib/modules/4.18.0-553.34.1.el8_10.x86_64/vmlinux /home2/memdump/vmss.core
crash: cannot resolve "p2m_top"

Any advice on how to properly analyze this dump or work around the p2m_top error? Thanks.

How to create a new process with the session ID (setsid) of an existing process? I have an idea using GDB which is working partly. But I'm also thankful for other approaches. . There seems to be no syscall where I can specify a session ID for a process. But I was inspired by another conversation , where GDB is being used. So my idea is, to use GDB to fork a process from an existing one with the desired session ID. The basic idea seems to work. But it suffers from a segmentation fault in the original process.

# start some long running process in it's own session
setsid --fork bash -c 'echo $$; sleep 1000'
# outputs it's PID == SESSION_ID (lets assume "100")

gdb --init-eval-command='set follow-fork-mode child' -p SESSION_ID

# in gdb:
call (int)fork()
# PROBLEM: original command outputs:
#   Segmentation fault      (core dumped) sleep 1000
call (int)execl("/bin/sleep", "sleep", "50")

ps --sid SESSION_ID -o pid,sid,args
#  101  100  sleep 50
#  102  100  sleep 120

So the original process "100" has crashed. But the new process successfully started. Any idea how to avoid the segfault? Related: Is there a way to change the process group of a running process?

I know that I can use CTRL+ALT+J in gdb to get vim keybindings but how do I get gdb to start in vi mode by default ?

I have a Python script that is running subprocesses that calls gdb --batch. That script needs to handle Control-C (SIGINT). While one of the GDB subprocesses is running, if I send a Control-C on the terminal, rather than the signal going to the script it goes to GDB. After the GDB job(s) exit, Control-C then correctly will go to the script again. I believe this is because GDB is establishing itself as a controlling terminal. Then when GDB exits the controlling terminal (due to other IO etc) returns to the script. 1. Is there a way to tell GDB not to take the controlling terminal? I looked at the GDB sources and I don't see a way it can be told to do an open() with O_NOCTTY which I suspect would do this. I'm not willing to recompile GDB. Perhaps some hack using a pseudo-TTY somehow? 2. If not, is there a way for my script to "take back" the controlling terminal? Note GDB needs to continue to run in the other process. I suspect I could make a new subprocess, make that the process leader, then do a TTY open, which would make it the lead, then close the subprocess, would that work? I dislike this as a hack. Note I don't want to disassociate the subprocesses from the script's process group. Thanks

I'm trying to run GDB remote debugging on a single source file, very basic C code, and I'm hitting a wall on something that seems like it should be completely obvious. Specifically, I cannot figure out how to get GDB to find the boundaries of procedures defined within this single file, making it impossible to use either step or next when execution reaches any procedure call. My environment: - Dockerized container, running Ubuntu 22.04 - Two shell windows, both on the same host, both under the same container image - RISCV-64 emulation under QEMU: using qemu-riscv64, symlinked as qemu - GCC for RISCV-64, riscv64-unknown-linux-gnu-gcc, symlinked as gcc - Using riscv64-unknown-linux-gnu-gdb, symlinked as gdb The source file is a basic selection sort demo, with bugs, compiled with

root@75229e1158dd:~# gcc -g -std=c99 -Wall -Werror buggy_sel_sort.c -o buggy_sel_sort

In one window, I start up QEMU for remote debugging:

root@75229e1158dd:~# qemu -g 1234 buggy_sel_sort

In the other, I invoke GDB with:

root@75229e1158dd:~# gdb  -ex 'target remote localhost:1234' -ex 'set sysroot /opt/riscv/' buggy_sel_sort
GNU gdb (GDB) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-pc-linux-gnu --target=riscv64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from buggy_sel_sort...
Remote debugging using localhost:1234
Reading symbols from /opt/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
(No debugging symbols found in /opt/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1)
0x0000001555d6b9f4 in _start () from /opt/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
(gdb)

So far, so good, at least I think so; my understanding is that the "dynamic linker breakpoint" warning can be ignored. I get the GDB prompt, set the breakpoint at main, and restart execution:

(gdb) break main
Breakpoint 1 at 0x1086c: file buggy_sel_sort.c, line 64.
(gdb) continue
Continuing.
warning: Could not load shared library symbols for 3 libraries, e.g. linux-vdso.so.1.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main (argc=1, argv=0x1555d56d18) at buggy_sel_sort.c:64
64          long test_array = {1,4,2,0,3};
(gdb) step
65          long test_array2 = {0xddad409b, 0x6b401dbe, 0xc59beda0, 0xf29ec713,

But the next line is a call to a selection_sort procedure, and this is where it goes off the rails:

(gdb) step
0x0000001555d667e4 in ?? ()
(gdb) step
Cannot find bounds of current function

Unsurprisingly, next doesn't fare any better. I can advance instructions using stepi or nexti, but all I get from that is information about the next instruction address. As you can probably tell, this is for a teaching project, so low-level representation like that really isn't helpful for beginners. What's strange to me is that I can add explicit breakpoints for all the procedure names in the source file; continue will reach their entry points, and finish their returns. I can step through their bodies until the next call. There has to be a better way around this. What am I missing that is making these procedure entry/exit points unfindable? FWIW, here is the output of info sharedlibrary:

(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
                                        No          linux-vdso.so.1
                                        No          /lib/libc.so.6
                                        No          /lib/ld-linux-riscv64-lp64d.so.1

I am having trouble with gdb. When I start pushing the Up Arrow key, it iterates backwards through the history. However, if I start typing a command, like b, instead of iterating only through history entries beginning with b, gdb still iterates backwards through all the history. The regular terminal (zsh) is fine. How do I make gdb iterate only through the history with the relevant commands?

New noob here. Using MX Linux, set up Mutt with gmail. Was initially successful. Emails and all. Then at some point when trying to use again, it stuck at 4% giving a segmentation fault. Using gdb it says: Fetching message headers... 6202/132349 (4%) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 (gdb) bt #0 0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 #1 0x00007ffff7c2fca8 in tcbdbput () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 #2 0x000055555561e5da in ?? () #3 0x000055555561eded in ?? () #4 0x000055555562dfe3 in ?? () #5 0x000055555562bb1c in ?? () #6 0x000055555562893d in ?? () #7 0x00005555555b774e in ?? () #8 0x000055555556c3ea in ?? () #9 0x00007ffff795cd7a in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x000055555556d44a in ?? () What do I do?

I asked this question in the reverse engineering stackexchange: https://reverseengineering.stackexchange.com/questions/15169/transferring-control-of-ptrace-to-another-process because I thought a ptrace question was most appropriate there. I didn't get any bites, I don't know if that is because there are too few people there, or they are not that familiar with linux. In any event, I thought I would ask here. I would like to create a process A. In A I would like to start a second process B. I would like A to go on and monitor system resources. When certain conditions are met I want A to ptrace B, start gdb and transfer ptrace control to gdb. Is this possible? If not is there a way A can pause B, start gdb with B atttached and then "unpause" B?

I was re-doing what described here about multiprocessing debugging in GDB. The weird thing is that GDB doesn't hit the exec catchpoint on the child process running cat command (the latter is forked off from bash). ubuntu@ubuntu:~$ echo $$ 670639 ubuntu@ubuntu:~$ cat /etc/issue root@ubuntu:~# gdb -q -p 670639 Attaching to process 670639 Reading symbols from /usr/bin/bash... (No debugging symbols found in /usr/bin/bash) Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.6... (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so.6) Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug... Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". pselect64_syscall (sigmask=0x564025a0c820 , timeout=, exceptfds=0x0, writefds=0x0, readfds=0x7ffe468736e0, nfds=1) at ../sysdeps/unix/sysv/linux/pselect.c:34 34 ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory. (gdb) catch fork Catchpoint 1 (fork) (gdb) catch exec Catchpoint 2 (exec) (gdb) c Continuing. Catchpoint 1 (forked process 719946), arch_fork (ctid=0x7fbccdc6fa10) at ../sysdeps/unix/sysv/linux/arch-fork.h:52 52 ../sysdeps/unix/sysv/linux/arch-fork.h: No such file or directory. (gdb) info inferiors Num Description Connection Executable * 1 process 670639 1 (native) /usr/bin/bash (gdb) set detach-on-fork off (gdb) nexti [New inferior 2 (process 719946)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 52 in ../sysdeps/unix/sysv/linux/arch-fork.h (gdb) c Continuing. What is the reason behind it? Thanks.

I built a docker image with gcc binutils and gdb debugger installed inside. I would attach gdb from that docker container to a process inside a lxc container running on the same Linux host. The lxc container uses its own PID namespace, therefore gdb running in the docker container complains that target process and debugger are not in the same PID namespace. [SR-PCE-251:~]$ docker run -it --pid host --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined carlo/ubuntu root@e7b2db23af34:/# root@e7b2db23af34:/# id uid=0(root) gid=0(root) groups=0(root) root@e7b2db23af34:/# root@e7b2db23af34:/# gdb -q attach 11365 attach: No such file or directory. Attaching to process 11365 [New LWP 24283] [New LWP 20025] [New LWP 20024] [New LWP 19992] [New LWP 19991] [New LWP 13974] [New LWP 13970] [New LWP 13969] [New LWP 13968] [New LWP 13967] [New LWP 13962] [New LWP 13958] [New LWP 13957] [New LWP 13954] [New LWP 13952] [New LWP 13944] [New LWP 12078] [New LWP 11822] [New LWP 11543] [New LWP 11515] [New LWP 11489] [New LWP 11483] [New LWP 11482] [New LWP 11477] [New LWP 11476] warning: "target:/proc/11365/exe": could not open as an executable file: Operation not permitted. warning: `target:/proc/11365/exe': can't open to read symbols: Operation not permitted. warning: Could not load vsyscall page because no executable was specified warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable. Connect to gdbserver inside the container. 0x00007f0bf997ac73 in ?? () (gdb) Edited to provide more information based on comments received [host:/gdb-install]$ id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [host:/gdb-install]$ [host:/gdb-install]$ ls -la total 24 drwxrwxr-x. 6 1000 1000 4096 Nov 14 09:32 . drwxr-xr-x. 30 root root 4096 Nov 14 11:27 .. drwxrwxr-x. 2 1000 1000 4096 Nov 14 09:32 bin drwxrwxr-x. 3 1000 1000 4096 Nov 14 09:32 include drwxrwxr-x. 2 1000 1000 4096 Nov 14 09:32 lib drwxrwxr-x. 6 1000 1000 4096 Nov 14 09:32 share [host:/gdb-install]$ [host:/gdb-install]$ export LD_LIBRARY_PATH=/gdb-install/bin:/gdb-install/lib [host:/gdb-install]$ ./bin/gdb ./bin/gdb: error while loading shared libraries: libmpfr.so.6: cannot open shared object file: No such file or directory [host:/gdb-install]$

I am running kernel 6.1 on ARM zynq7. I have written some external kernel modules which i think are causing some kernel Oops but i can figure out where. So i ran GDB via serial connection. This is what i get but i am not sure how to interpret this.

Continuing.
[New Thread 706]
[New Thread 707]
[New Thread 708]

Thread 1 received signal SIGSEGV, Segmentation fault.
rb_add_cached (less=, tree=0xef7d3014, node=0xef7d3320) at ./include/linux/rbtree.h:177
177				link = &parent->rb_right;
(gdb) bt 15
#0  rb_add_cached (less=, tree=0xef7d3014, node=0xef7d3320) at ./include/linux/rbtree.h:177
#1  timerqueue_add (head=0xef7d3014, head@entry=0x1, node=node@entry=0xef7d3320) at lib/timerqueue.c:40
#2  0xc0189570 in enqueue_hrtimer (mode=HRTIMER_MODE_ABS, base=, timer=0xef7d3320) at kernel/time/hrtimer.c:1091
#3  __run_hrtimer (now=, flags=, timer=0xef7d3320, base=0xef7d3000, cpu_base=) at kernel/time/hrtimer.c:1702
#4  __hrtimer_run_queues (cpu_base=cpu_base@entry=0xef7d2fc0, now=, flags=flags@entry=536936851, active_mask=active_mask@entry=15)
    at kernel/time/hrtimer.c:1749
#5  0xc0189d78 in hrtimer_interrupt (dev=) at kernel/time/hrtimer.c:1811
#6  0xc010d454 in twd_handler (irq=, dev_id=) at arch/arm/kernel/smp_twd.c:185
#7  0xc016dd94 in handle_percpu_devid_irq (desc=0xc1018600) at kernel/irq/chip.c:930
#8  0xc01685d0 in generic_handle_irq_desc (desc=) at ./include/linux/irqdesc.h:158
#9  handle_irq_desc (desc=) at kernel/irq/irqdesc.c:646
#10 generic_handle_domain_irq (domain=, hwirq=) at kernel/irq/irqdesc.c:702
#11 0xc0401f10 in gic_handle_irq (regs=) at drivers/irqchip/irq-gic.c:372
#12 0xc08c87e8 in generic_handle_arch_irq (regs=0xc0e01ec8) at kernel/irq/handle.c:242
#13 0xc0100ba8 in __irq_svc () at arch/arm/kernel/entry-armv.S:221
#14 0xc0100ba8 in __irq_svc () at arch/arm/kernel/entry-armv.S:221
(More stack frames follow...)

None of my modules use high res timers. I do have a module that uses IRQ from FPGA. My question is how can i tell what is complaining/casuing the seg fault? Is it the first call rb_add_cached ? I currently cant exactly reproduce the error other than letting the modules run for 10s of seconds. Basically its getting packet data and sending it to mac80211 via a custom driver.

I am trying to debug a Linux kernel v5.15 running on a QEMU/KVM virtual machine. My intention is to debug an external kernel module, specifically character device driver that I have written, which is generating a kernel panic. For this purpose, I am running Ubuntu on my virtual machine, so that I can install build tools, compile and install my driver. However, I am running into an issue when debugging my kernel module. I have built the kernel with the flags indicated in the documentation , run the virtual machine with the -s flag, and used this kernel to boot Ubuntu. I have inserted my module and followed the instructions in this article : 1) checked where it was loaded with cat /sys/module//sections/.text, then 2) I called add-symbol-file to load the module symbols in my gdb session. However, when I add a breakpoint on the last function before the kernel panic and hit continue, the VM freezes and if I run lx-dmesg in gdb I can see that the kernel panic occurred, meaning that the breakpoint was not hit. I am not entirely sure what information to pass to the add-symbol-file command. The GDB documentation says the following about the argument: > *address* should be the memory address at which the file has been loaded; GDB cannot figure this out for itself. I have tried passing the path to the .ko file in my host machine (as the ` argument), and the address where the module is loaded in my guest VM (as the ). Also I tried inserting the module on my host as well and passing its loaded address (on my host machine) as the ` parameter. Both of these attempts resulted on the aforementioned behavior. I am not sure whether it is a problem with the address that I am passing to the command, or a problem with the file path. I think its important to clarify that I *am* able to work with breakpoints on regular kernel functions, I am just having issues with breakpoints in my custom external kernel module. Is this the correct way of debugging externally loaded, out-of-tree modules? Should I try a different approach? I haven't been able to find much documentation on these cases. I would greatly appreciate any help or pointers to the right documentation for this.

I regularly run a GUI binary through CI tests using Github Actions. Occasionally, the binary crashes unexpectedly. This issue is difficult to reproduce, so I'd like to capture a stack trace whenever it occurs. To achieve this, I'm using xvfb-run and gdb: xvfb-run --auto-servernum gdb --batch -ex "run" -ex "bt full" --args ${{github.workspace}}/src/mudlet --profile 'Mudlet self-test' --mirror However, this command always exits with code 1, which according to the xvfb-run documentation, indicates an error in the child process (gdb). I believe gdb returns this exit code because there's typically no stack trace to print. As a workaround, I've added -ex "quit 0" to the GDB command, but this prevents the workflow from failing if a genuine crash happens. How can I reliably capture a stack trace when the binary crashes and avoid workflow failures when no issues occur?

I am debugging a small 32-bit binary to which I want to pass a specific environment using the env command like so:

# gdb -args env -i ./tiny_easy

Later in gdb I issue a catch syscall execve command so that env halts just before execve so I can continue debugging the original binary from its entry point. i.e. by single stepping with si. The problem is this does not happen:

# gdb -args env -i ./tiny_easy
GNU gdb (GDB) 15.1
...
Reading symbols from env...
(No debugging symbols found in env)
(gdb) catch syscall execve
Catchpoint 1 (syscall 'execve' )
(gdb) r
Starting program: /usr/bin/env -i ./tiny_easy
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Catchpoint 1 (call to syscall execve), 0x00007ffff7e9382b in execve () from /usr/lib/libc.so.6
(gdb) si
process 314196 is executing new program: /home/martician/tiny_easy

Program received signal SIGSEGV, Segmentation fault.
0x69742f2e in ?? ()
(gdb)

It looks like gdb doesn't stop at the binary's entry point but rather continues execution until it encounters a SIGSEGV. This is not what I would expect since si should step a single instruction and this is not what happens if I use 32-bit gdb and 32-bit env on a 32-bit machine:

tiny_easy@pwnable:~$ gdb -args env -i ./tiny_easy      
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
...
Reading symbols from env...(no debugging symbols found)...done.
(gdb) catch syscall execve 
Catchpoint 1 (syscall 'execve' )
(gdb) r
Starting program: /usr/bin/env -i ./tiny_easy

Catchpoint 1 (call to syscall execve), 0x00007ffff7ad97f7 in execve () at ../sysdeps/unix/syscall-template.S:84
84	../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) si
process 384951 is executing new program: /home/tiny_easy/tiny_easy

Catchpoint 1 (returned from syscall execve), 0x08048054 in ?? ()
(gdb) x/5i $pc                    
=> 0x8048054:	pop    eax <------- this is the entry point
   0x8048055:	pop    edx
   0x8048056:	mov    edx,DWORD PTR [edx]
   0x8048058:	call   edx <------- the 64-bit gdb does not halt at 0x8048054 but it SIGSEGVs upon this call (the SIGSEGV is expected)
   0x804805a:	add    BYTE PTR [eax],al
(gdb)

So the problem occurs on a 64-bit x86-64 machine with 64-bit versions of gdb and env while not on the respective 32-bit equivalents. What could be causing this behavior and is there a way to fix it? My best guess is that there is some gdb context I should manually change when doing the switch between the 64-bit env and the 32-bit binary but I can't find any sources online.

I'm trying to analyze core dump files of the systemd process, but encountering errors due to missing symbols. Can anyone advise what debug symbols need to be installed to successfully analyze these core dumps?

gdb  -e /usr/lib/systemd/systemd-journald -c core-systemd-journal--0-0-657-1718434887
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-20.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: core file may not match specified executable file.
[New LWP 657]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libuuid.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/d0/43572678e11cfb56aecb4ec534bc016de8d0d5.debug
Missing separate debuginfo for /lib64/libudev.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/94/5e15d6b231fc346823186cd70e886dede771ca.debug
Core was generated by `/usr/lib/systemd/systemd-journald'.
Program terminated with signal SIGABRT, Aborted.