[SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

gneg · 2026-03-14 19:59:54

Hi! I can’t debug C code, because GDB can’t access memory at address 0x1139.

This happens in all programs I’m trying to debug. For example, I’ve made a super
simple C program:

#include <stdio.h>

int main(void) {
	for (;;) {
		puts("hi");
	}
}

I compiled it with

gcc -ggdb3 main.c -o main

Then I tried to debug it with

gdb main

Here’s what happened next:

GNU gdb (GDB) 17.1
Copyright <...>

Reading symbols from main...
(gdb) list
1	#include <stdio.h>
2	
3	int main(void) {
4		for (;;) {
5			puts("hi");
6		}
7	}
(gdb) break main
Breakpoint 1 at 0x113d: file main.c, line 5.
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x000000000000113d in main at main.c:5
(gdb) run
Starting program: /tmp/main 
❌️ Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1139

Interestingly, the address of the break point is 0x113d, but GDB can’t access 0x1139.

I’ve searched the internet about this, but haven’t found anything helpful. What I’ve seen:

Gentoo: gdb accepts no breakpoint. They talk about “CONFIG_PROC_
MEM_FORCE_PTRACE.” I don’t know what it is.
Gentoo: GDB "Cannot Insert Breakpoint." This guy’s GDB doesn’t work
because his kernel is hardened. As far as I know, my kernel is not hardened.
I use regular linux-lts.
Arch: GDB can't insert breakpoint. This guy has a problem with /proc/sys/
kernel/yama/ptrace_scope. I can set it to 0, but it doesn’t help.

Other questions I’ve seen about this problem are unrelated, I think.

By the way, Delve, a Go debugger, works fine.

Help me fix my GDB!

Last edited by gneg (2026-03-19 17:48:37)

dimich · 2026-03-14 21:09:12

$ gdb --nh main

Does this work? If it does, show your ~/.config/gdb/*

gneg · 2026-03-15 16:38:52

I tried the command you suggested. Nothing changed, GDB behaves the same way.

dimich · 2026-03-15 17:13:11

$ pacman -Qkk gdb; expac "%D" gdb | xargs pacman -Qkk

$ expac "%D" gdb | xargs pacman -Q

gneg · 2026-03-15 17:45:22

~: pacman -Qkk gdb; expac "%D" gdb | xargs pacman -Qkk
gdb: 38 total files, 0 altered files
bash: 270 total files, 0 altered files
expat: 29 total files, 0 altered files
gcc-libs: 0 total files, 0 altered files
gdb-common: 99 total files, 0 altered files
backup file: glibc: /etc/locale.gen (Modification time mismatch)
backup file: glibc: /etc/locale.gen (Size mismatch)
backup file: glibc: /etc/locale.gen (SHA256 checksum mismatch)
glibc: 1625 total files, 0 altered files
gmp: 19 total files, 0 altered files
guile: 961 total files, 0 altered files
libelf: 117 total files, 0 altered files
xz: 458 total files, 0 altered files
mpfr: 30 total files, 0 altered files
ncurses: 3967 total files, 0 altered files
readline: 60 total files, 0 altered files
xxhash: 27 total files, 0 altered files
zstd: 39 total files, 0 altered files
mpfr: 30 total files, 0 altered files
ncurses: 3967 total files, 0 altered files
python: 3198 total files, 0 altered files
readline: 60 total files, 0 altered files
source-highlight: 434 total files, 0 altered files
xxhash: 27 total files, 0 altered files
xz: 458 total files, 0 altered files
zstd: 39 total files, 0 altered files

~: expac "%D" gdb | xargs pacman -Q
bash 5.3.9-1
expat 2.7.4-1
gcc-libs 15.2.1+r604+g0b99615a8aef-1
gdb-common 17.1-2
glibc 2.43+r5+g856c426a7534-1
gmp 6.3.0-3
guile 3.0.11-1
libelf 0.194-1
xz 5.8.2-1
mpfr 4.2.2-1
ncurses 6.6-1
readline 8.3.003-1
xxhash 0.8.3-1
zstd 1.5.7-3
mpfr 4.2.2-1
ncurses 6.6-1
python 3.14.3-1
readline 8.3.003-1
source-highlight 3.1.9-16
xxhash 0.8.3-1
xz 5.8.2-1
zstd 1.5.7-3

dimich · 2026-03-15 20:09:40

The only difference in package versions from mine is libelf 0.194-1 vs 0.194-2, but this doesn't seem to be the cause. Can't reproduce with either libelf 0.194-1 or 0.194-2.

Does the program run under gdb without breakpoint? Does it run without gdb at all?

Let's check /proc/ settings

$ sudo sysctl -a | grep "^\(kernel\|user\|vm\)\."

And kernel command line

$ xargs -n1 -a /proc/cmdline

seth · 2026-03-15 21:11:40

Did you https://wiki.archlinux.org/title/Debuginfod#Disabling ?
Can you share the compiled "main" binary?

type -a gcc
type -a gdb

Do you use the hardened kernel or engage in other efforts to harden the system?

gneg · 2026-03-16 09:15:29

Dmytro,

Yes, the program runs fine without a break point and outside of GDB.

~: doas sysctl -a | grep "^\(kernel\|user\|vm\)\."
kernel.acct = 4	2	30
kernel.acpi_video_flags = 0
kernel.arch = x86_64
kernel.auto_msgmni = 0
kernel.bootloader_type = 33
kernel.bootloader_version = 1
kernel.bpf_stats_enabled = 0
kernel.cad_pid = 1
kernel.cap_last_cap = 40
kernel.core_file_note_size_limit = 4194304
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F
kernel.core_pipe_limit = 16
kernel.core_sort_vma = 0
kernel.core_uses_pid = 1
kernel.ctrl-alt-del = 0
kernel.dmesg_restrict = 1
kernel.domainname = (none)
kernel.ftrace_dump_on_oops = 0
kernel.ftrace_enabled = 1
kernel.hardlockup_all_cpu_backtrace = 0
kernel.hardlockup_panic = 0
kernel.hostname = billy
kernel.hung_task_all_cpu_backtrace = 0
kernel.hung_task_check_count = 4194304
kernel.hung_task_check_interval_secs = 0
kernel.hung_task_panic = 0
kernel.hung_task_timeout_secs = 120
kernel.hung_task_warnings = 10
kernel.io_delay_type = 0
kernel.io_uring_disabled = 0
kernel.io_uring_group = -1
kernel.kexec_load_disabled = 0
kernel.kexec_load_limit_panic = -1
kernel.kexec_load_limit_reboot = -1
kernel.keys.gc_delay = 300
kernel.keys.maxbytes = 20000
kernel.keys.maxkeys = 200
kernel.keys.persistent_keyring_expiry = 259200
kernel.keys.root_maxbytes = 25000000
kernel.keys.root_maxkeys = 1000000
kernel.kptr_restrict = 0
kernel.max_lock_depth = 1024
kernel.max_rcu_stall_to_panic = 0
kernel.modprobe = /sbin/modprobe
kernel.modules_disabled = 0
kernel.msg_next_id = -1
kernel.msgmax = 8192
kernel.msgmnb = 16384
kernel.msgmni = 32000
kernel.ngroups_max = 65536
kernel.nmi_watchdog = 1
kernel.ns_last_pid = 31041
kernel.numa_balancing = 0
kernel.numa_balancing_promote_rate_limit_MBps = 65536
kernel.oops_all_cpu_backtrace = 0
kernel.oops_limit = 10000
kernel.osrelease = 6.12.74-1-lts
kernel.ostype = Linux
kernel.overflowgid = 65534
kernel.overflowuid = 65534
kernel.panic = 0
kernel.panic_on_io_nmi = 0
kernel.panic_on_oops = 0
kernel.panic_on_rcu_stall = 0
kernel.panic_on_unrecovered_nmi = 0
kernel.panic_on_warn = 0
kernel.panic_print = 0
kernel.perf_cpu_time_max_percent = 25
kernel.perf_event_max_contexts_per_stack = 8
kernel.perf_event_max_sample_rate = 79200
kernel.perf_event_max_stack = 127
kernel.perf_event_mlock_kb = 516
kernel.perf_event_paranoid = 2
kernel.pid_max = 4194304
kernel.poweroff_cmd = /sbin/poweroff
kernel.print-fatal-signals = 0
kernel.printk = 3	4	1	4
kernel.printk_delay = 0
kernel.printk_devkmsg = on
kernel.printk_ratelimit = 5
kernel.printk_ratelimit_burst = 10
kernel.pty.max = 4096
kernel.pty.nr = 1
kernel.pty.reserve = 1024
kernel.random.boot_id = 82d3f60b-b5ae-4d6f-92a7-3260637893c6
kernel.random.entropy_avail = 256
kernel.random.poolsize = 256
kernel.random.urandom_min_reseed_secs = 60
kernel.random.uuid = 10dca283-002f-41b4-ac90-4f59aadd8b90
kernel.random.write_wakeup_threshold = 256
kernel.randomize_va_space = 2
kernel.real-root-dev = 0
kernel.sched_autogroup_enabled = 1
kernel.sched_cfs_bandwidth_slice_us = 5000
kernel.sched_deadline_period_max_us = 4194304
kernel.sched_deadline_period_min_us = 100
kernel.sched_rr_timeslice_ms = 100
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 950000
kernel.sched_schedstats = 0
kernel.sched_util_clamp_max = 1024
kernel.sched_util_clamp_min = 1024
kernel.sched_util_clamp_min_rt_default = 1024
kernel.seccomp.actions_avail = kill_process kill_thread trap errno user_notif trace log allow
kernel.seccomp.actions_logged = kill_process kill_thread trap errno user_notif trace log
kernel.sem = 32000	1024000000	500	32000
kernel.sem_next_id = -1
kernel.shm_next_id = -1
kernel.shm_rmid_forced = 0
kernel.shmall = 18446744073692774399
kernel.shmmax = 18446744073692774399
kernel.shmmni = 4096
kernel.soft_watchdog = 1
kernel.softlockup_all_cpu_backtrace = 0
kernel.softlockup_panic = 0
kernel.split_lock_mitigate = 1
kernel.stack_tracer_enabled = 0
kernel.sysctl_writes_strict = 1
kernel.sysrq = 16
kernel.tainted = 0
kernel.task_delayacct = 0
kernel.threads-max = 28783
kernel.timer_migration = 1
kernel.traceoff_on_warning = 0
kernel.tracepoint_printk = 0
kernel.unknown_nmi_panic = 0
kernel.unprivileged_bpf_disabled = 2
kernel.unprivileged_userns_clone = 1
kernel.user_events_max = 32768
kernel.usermodehelper.bset = 4294967295	511
kernel.usermodehelper.inheritable = 4294967295	511
kernel.version = #1 SMP PREEMPT_DYNAMIC Thu, 19 Feb 2026 16:48:19 +0000
kernel.warn_limit = 0
kernel.watchdog = 1
kernel.watchdog_cpumask = 0-1
kernel.watchdog_thresh = 10
kernel.yama.ptrace_scope = 1
user.max_cgroup_namespaces = 14391
user.max_fanotify_groups = 128
user.max_fanotify_marks = 30992
user.max_inotify_instances = 1024
user.max_inotify_watches = 524288
user.max_ipc_namespaces = 14391
user.max_mnt_namespaces = 14391
user.max_net_namespaces = 14391
user.max_pid_namespaces = 14391
user.max_time_namespaces = 14391
user.max_user_namespaces = 14391
user.max_uts_namespaces = 14391
vm.admin_reserve_kbytes = 8192
vm.compact_unevictable_allowed = 1
vm.compaction_proactiveness = 20
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
vm.enable_soft_offline = 1
vm.extfrag_threshold = 500
vm.hugetlb_optimize_vmemmap = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256	256	32	0	0
vm.max_map_count = 1048576
vm.memfd_noexec = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 65536
vm.mmap_rnd_bits = 32
vm.mmap_rnd_compat_bits = 16
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.numa_stat = 1
vm.numa_zonelist_order = Node
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.page_lock_unfairness = 5
vm.panic_on_oom = 0
vm.percpu_pagelist_high_fraction = 0
vm.stat_interval = 1
vm.swappiness = 60
vm.unprivileged_userfaultfd = 0
vm.user_reserve_kbytes = 118956
vm.vfs_cache_pressure = 100
vm.watermark_boost_factor = 15000
vm.watermark_scale_factor = 10
vm.zone_reclaim_mode = 0

~: xargs -n1 -a /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-linux-lts
root=UUID=dc8c4501-4303-4ca4-8be5-3041421c513d
rw
quiet
loglevel=3
udev.log_level=3
efi=runtime

seth,

The problem is present both when DEBUGINFOD_URLS are set and when they aren’t.
I didn’t do anything to harden my system (probably :). I use a regular linux-lts.

Main binary: https://0x0.st/PL6E.bin

GCC and GDB are from Pacman.

~: type -a gcc
gcc is /usr/bin/gcc
gcc is /bin/gcc
~: type -a gdb
gdb is /usr/bin/gdb
gdb is /bin/gdb

dimich · 2026-03-16 09:58:05

Nothing in /proc/sys/ or cmdline looks suspicious. The binary is the same as mine (obviously except build-id and paths in debug info).

I observed similar (but not the same) issue when using gdb-dashboard extension, so suspecting some third-party gdb extension can affect.
Actually '--nh' disables only user-specific initialization files. Can you try 'gdb --nx ./main' to disable all initialization files?
Also, does anything appear in dmesg after the error occurs?

gneg · 2026-03-16 10:26:30

I don’t have any GDB extensions, as far as I know. gdb --nx fails the same way.
Nothing new appears in dmesg.

dimich · 2026-03-16 11:20:56

$ gdb --batch -ex 'file ./main' -ex 'set debug break' -ex 'break main' -ex 'run'

Also, does the error occur when running gdb as root?

gneg · 2026-03-16 12:25:47

Yes, it works under root!! But why?..

Your command:

~: gdb --batch -ex 'file ./main' -ex 'set debug break' -ex 'break main' -ex 'run'
Breakpoint 1 at 0x113d: file main.c, line 5.
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
[breakpoint] insert_bp_location: Breakpoint 1 (0x5f49717c8440) at address 0x1139 in main at main.c:3
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1139

seth · 2026-03-16 13:57:58

Does

env -i gdb ./main

work?

dimich · 2026-03-16 14:08:29

gneg wrote:

Yes, it works under root!! But why?..

For me it looks like some security module or other hardening facility in action.

$ xargs -n1 -d, -a /sys/kernel/security/lsm

gneg · 2026-03-17 18:01:10

seth,

Yes, env -i works! I tested all of my environment variables, and found out that
SHELL is what breaks GDB. When I set it to /bin/sh, GDB works fine. But I don’t
understand what’s wrong with my usual SHELL.

My SHELL points to ~/bin/fishlogin. It’s a hack to run Fish with a profile written
in Bash:

#!/bin/bash -l
. /home/gneg/profile
exec -l fish "$@"

I use this as a login shell, so bash in the shebang has -l. I can’t recall why
I use exec -l instead of just exec though. Removing -l has no effect. Fish
is also not the problem; if I change SHELL to /bin/fish, GDB works fine.
Commenting out the line that sources the profile doesn’t help either.

So there’s something wrong with this script, but I don’t know what.
For now, I’ve just set SHELL to /bin/fish. GDB works.

Dmytro,
Turns out it’s not because of hardening :)

seth · 2026-03-17 20:35:00

I'd recommed to do the opposite: https://wiki.archlinux.org/title/Fish#M … _into_fish
Or alternatively (realistically) keep bash or zsh as login shell and run your GUI TE "-e fish" (they'll typically default to $SHELL - which you also don't want to unconditionally be a login shell - but allow you to run arbitrary commands instead)

I then heavily suspect that the exec itself offsets the stack for GDB ¯\_(ツ)_/¯

dimich · 2026-03-18 09:59:39

gdb/nat/fork-inferior.h:28

/* Number of traps that happen between exec'ing the shell to run an
   inferior and when we finally get to the inferior code, not counting
   the exec for the shell.  This is 1 on all supported
   implementations.  */
#define START_INFERIOR_TRAPS_EXPECTED 1

dimich · 2026-03-18 13:23:54

gneg wrote:

My SHELL points to ~/bin/fishlogin.
I use this as a login shell

Offtopic: this may cause other issues since valid login shells are listed in /etc/shells.

dimich · 2026-03-18 21:50:12

Digging in gdb sources found an option to execute inferior directly rather than via shell: set startup-with-shell off

$ SHELL=$PWD/pseudoshell gdb ./main
Reading symbols from ./main...
(gdb) break main
Breakpoint 1 at 0x113d: file main.c, line 6.
(gdb) run
Starting program: /tmp/main 
❌ Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1139

(gdb) set startup-with-shell off
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/main 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, main () at main.c:6
6               puts("hello");
(gdb)

gneg · 2026-03-19 17:47:34

So the problem occurs because GDB isn’t friends with exec. I’ve solved the problem
by setting SHELL to /bin/fish in the profile. This way, we run my Fishlogin script only
once, as a login shell, and all the child shells are just Fishes.

seth wrote:

I'd recommed to do the opposite: https://wiki.archlinux.org/title/Fish#M … _into_fish

I don’t really like this solution. In its simplest form, it always replaces Bash with Fish,
and I want to use Bash sometimes. And when it gets smarter and tries to guess when
to be Bash and when to be Fish, it starts feeling clumsy to me. I think my solution is
more simple and robust.

Is this solution better than mine in some ways?

dimich wrote:

Offtopic: this may cause other issues since valid login shells are listed in /etc/shells.

Digging in gdb sources found an option to execute inferior directly rather than via shell: set startup-with-shell off

I’ll keep that in mind.

The problem is solved, so I’m marking this thread as solved.
Thank you so much for help, guys!

seth · 2026-03-19 20:03:27

Is this solution better than mine in some ways?

The immediate case aside you're probably not interested in a non-interactive fish and everything executing $SHELL will face the more common bash (so you're not running into compatibility issues there)
You might not even be interested in anything but

seth wrote:

keep bash or zsh as login shell and run your GUI TE "-e fish"

If you want to force a bash you btw. don't *have* to rely on guesswork, you can inspect eg. "$NOFISH"

gneg · 2026-03-20 14:26:31

you're probably not interested in a non-interactive fish

True.

You might not even be interested in anything but keep bash or zsh as login shell and run your GUI TE "-e fish"

No, I want Fish to be my login shell. I sometimes use it—for example, when my window
manager breaks or when I want to switch to a different one.

everything executing $SHELL will face the more common bash (so you're not running into compatibility issues there)

I’m not running into compatibility issues, since we’ve fixed the one with GDB :)
But I’ll keep this in mind. If I run into some issues, I’ll consider changing my SHELL.

Arch Linux

#1 2026-03-14 19:59:54

[SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#2 2026-03-14 21:09:12

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#3 2026-03-15 16:38:52

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#4 2026-03-15 17:13:11

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#5 2026-03-15 17:45:22

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#6 2026-03-15 20:09:40

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#7 2026-03-15 21:11:40

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#8 2026-03-16 09:15:29

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#9 2026-03-16 09:58:05

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#10 2026-03-16 10:26:30

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#11 2026-03-16 11:20:56

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#12 2026-03-16 12:25:47

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#13 2026-03-16 13:57:58

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#14 2026-03-16 14:08:29

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#15 2026-03-17 18:01:10

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#16 2026-03-17 20:35:00

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#17 2026-03-18 09:59:39

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#18 2026-03-18 13:23:54

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#19 2026-03-18 21:50:12

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#20 2026-03-19 17:47:34

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#21 2026-03-19 20:03:27

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

#22 2026-03-20 14:26:31

Re: [SOLVED] gdb: Cannot insert breakpoint 1. Cannot access memory at addr

Board footer