“Cannot access memory at address” after gdb catch syscall on Raspbian

[RomanMeR]

I’m new to gdb and Linux, so please excuse me if my situation will appear to be not a bug. I’m investigating a performance issue with my Python script on a Raspberry Pi 3. It runs official Raspbian operating system. I need to set catchpoint on a certain system call (gettimeofday, also tried futex), so the need arises in using gdb and not the Python debugger. I use GDB preinstalled in Raspbian. I installed python2.7-dbg package in order to have Python extensions for gdb: sudo apt-get install python2.7-dbg After that I run my script under gdb and issue (gdb) catch syscall gettimeofday (see typescript file attached for full log). After 1st breakpoint hit and issuing the “continue” command 2 times, the following error message appears:

Cannot access memory at address 0x76e3b964

If I examine the /proc//maps file, I see that this address is indeed not a part of my Python’s process address space. After this error I see that my application is not running. If I issue “continue” to gdb again, the following message is displayed:

Cannot execute this command while the selected thread is running.

If I issue "stop" debugging is not stopped, Python process remains. If I issue "quit" and then "y", gdb seems to hang. After some time I kill it together with Python process. If I run that Python script under gdb without issuing “catch syscall”, the program works well and gdb doesn’t output any errors (except SIGILL in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 which I believe is normal).

I suppose the “Cannot access memory at address 0x76e3b964” error after "catch syscall" is a bug. My expectation is that after “catch syscall” Python process runs without errors and breakpoint is hit when corresponding system function is called.

Additional information:

GDB version: GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1

GDB configuration: This GDB was configured as follows: configure --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --with-expat --with-gdb-datadir=/usr/share/gdb (relocatable) --with-jit-reader-dir=/usr/lib/gdb (relocatable) --without-libunwind-ia64 --with-lzma --with-python=/usr (relocatable) --with-separate-debug-dir=/usr/lib/debug (relocatable) --with-system-gdbinit=/etc/gdb/gdbinit --with-zlib --without-babeltrace

("Relocatable" means the directory can be moved with the GDB installation tree, and GDB will still find it.)

uname -a: Linux s21volnaya5 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

[popcornmix]

This repo is for linux kernel bugs. This sounds like an issue with gdb. Might be worth asking in forum in case others have seen a similar problem. Or you could create a bug report with gdb: https://www.gnu.org/software/gdb/bugs/

[RomanMeR]

There are several reasons why I decided to report this problem here:

1. There is the following note on the Bugs in GDB web page you mentioned:

Please note that many companies now redistribute GDB, often as part of a GNU/Linux distribution. When you find bugs in GDB that you installed with a given GNU/Linux distribution, it is often useful to first try reporting the bug directly to the distributor, not to us. Sometimes, distributors have modified the GNU software (as they are free to do so!) or they are running older versions. Thus, they may be the best people to find a bug as it pertains to a particular distribution.

2. I searched through issues in this repo and found the SIGILL on using GDB, in ld-linux-armhf.so.3 issue, and I thought that this place is suitable for GDB-related issues (especially together with previous reason).

3. I searched through forums on www.raspberrypi.org and found one relatively useful topic: Raspbian GDB broken (see posts on March 2017). I haven't tried that solution yet. But even if it works, I thought it would be great for GDB in Raspbian to work without the subj error and without need to manually rebuild it.

Now I'm lost and don't know what to do with subj problem. Should I dismiss reason 1 and still post bug to GDB project directly? But, on the other hand, GDB version in Raspbian is relatively old, so maybe I should first try recipe from the Raspbian GDB broken forum topic? If it will help, then what should I do in order for the new GDB version to be included in Raspbian updates?

[popcornmix]

As I said, this repo is for linux kernel bugs. This doesn't sound like a linux kernel bug.

I would have though that most likely the issue lies in the gdb source code and so the gdb project is the best place to get it resolved.

If you determine that a newer/patched version of gdb avoids the issue, then it may be worth reporting to: https://github.com/RPi-Distro/repo

which handles packaging of software included with raspbian.

[RomanMeR]

@popcornmix Thank you very much for guiding me in the right direction!

[RomanMeR]

In case anyone interested, here is the link to subj issue in the GNU GDB bugtracker: Bug 21372 - “Cannot access memory at address” after catch syscall on Raspbian

[JamesH65]

Closing as this issue is not kernel related.