gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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!

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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 13:57:58

Does

env -i gdb ./main

work?

dimich · Yesterday 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

Arch Linux

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

gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

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

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#8 Yesterday 09:15:29

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#9 Yesterday 09:58:05

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#10 Yesterday 10:26:30

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#11 Yesterday 11:20:56

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#12 Yesterday 12:25:47

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#13 Yesterday 13:57:58

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

#14 Yesterday 14:08:29

Re: gdb: Cannot insert breakpoint 1. Cannot access memory at address 0x

Board footer