gdb always returns segmentation fault

Question

I'm trying to use gdb (Ubuntu 12.1) on my Ubuntu VM (22.04.1 LTS), but whenever I try the run command it always gives a segmentation fault, regardless of the program being debugged.

(gdb) run
Starting program: /home/dir/a.out

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

This happens even with -g GCC option.

What's interesting is that on my laptop, with the same Ubuntu VM installed and same gcc/gdb versions, gdb works just fine. So I really don't understand what causes the problem.

I uninstalled and reinstalled both gcc and gdb, and even successfully ran a sudo apt update and consequent sudo apt upgrade, but that segmentation fault's still there.

EDIT: haven't found similar problems on the Internet, but I think that the cause of my problem could be VirtualBox (7.0.4), on which runs Ubuntu, that apparently is not completely supported by MacOS Ventura yet.

I only set `set disassembly-flavor intel` in my `~/.gdbinit`. But even if I delete it, gdb continues to return the segmentation fault error. — LeoPipo, Nov 21 '22 at 22:21
If you type `start` or `starti` instead of `run`, does it segfault? — Mark Plotnick, Nov 22 '22 at 09:36
Does it do the same with any program? Can you just try to gdb one of your system files? idk .. bash maybe? — AndreasT, Jan 03 '23 at 11:37

Lakshana Ravishankar · Answer 1 · 2023-02-26T07:53:49.493

0

You could try downgrading to VirtualBox 6.1. I faced similar issues with VirtualBox 7.0.6 on MacOS Monterey, but then the problem was sorted after I downgraded to VirtualBox 6.1.42.

If that does not work, then the issue might be with Ventura.

edited Feb 26 '23 at 07:53

answered Feb 26 '23 at 07:51

Lakshana Ravishankar

31
4

score 0 · Answer 2 · answered Aug 22 '23 at 14:32

The "0x0000aaaa9aa5ac89" is a suspicious address, which might lead to the root cause of this SEGV. I encountered a similar SEGV in gdb while loading the program's shared libraries in dl_main (glibc, pre main()), and I'm documenting it here in case it helps someone.

In my case, dl_main was causing SEGV. The setup was gdb debugging a remote program running under gdbserver. The host gdb was controlled by vscode with the setting "stopAtConnect: true".

I was able to resolve my SEGV by installing the same version of glibc on both the gdb host and the debug target running gdbserver.

I believe what was happening is that the stopAtConnect setting was inserting a breakpoint into the target process, but using the host debug symbol information, which was from a different version of glibc. I think the inserted breakpoint bytes altered some machine instruction in the target process such that it was doing something invalid.

gdb always returns segmentation fault

2 Answers2

Linked