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

[ibuclaw]

Expected Behavior

What should have happened is ... gdb works

Real Behavior

What ended up happening was ... gdb doesn't work, fails with a message like:

Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x555555555131

Can be reproduced running with ssh terminal access:

# cat > test.c << EOF
int main()
{
    return 0;
}
EOF
# gcc -g test.c
# gdb a.out
# gdb a.out 
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x1131: file test.c, line 3.
Starting program: /tmp/cirrus-ci-build/a.out 
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x555555555131

(gdb) 

Related Info

This is a (tick one of the following):

• Task issue
  • container image: ubuntu:22.04

The container image ubuntu:1804 does not have the same problem, which might mean they're running on different hosts.

[RDIL]

So, you are trying to run GDB in a remotely connected task?

[ibuclaw]

So, you are trying to run GDB in a remotely connected task?

Yes, there are a number of tests in our testsuite that verify the dwarf info generated for a compiled module can be used by gdb for debugging the program.

[edigaryev]

This seems to be a bug in the GDB, which at some point removed the ptrace(2) fallback when /dev/[pid]/mem is not available (see bminor/binutils-gdb@05c06f3), but this seems to be now fixed in bminor/binutils-gdb@dd09fe0. However, this commit didn't made it to the release yet.

Source: microsoft/WSL#8356 (comment).

You can work around this by requesting a privileged container using a kvm option:

task:
  container:
    image: ubuntu:22.04
    kvm: true

  install_script:
    - apt-get update
    - apt-get -y install gdb gcc

  compile_script: ...

  debug_script: ...