gef: gdb_exception_RETURN_MASK_ERROR

Step 0:

Yes, yes, yes

Step 1: Describe your environment

Operating System: Linux 4.9.78-v7+
Architecture: armv7l Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Model: 4 Model name: ARMv7 Processor rev 4 (v7l) CPU max MHz: 1200.0000 CPU min MHz: 600.0000 BogoMIPS: 38.40 Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
GDB version (including the Python library version): Debian 7.12-6+b1, Python 2.7/3.7

Step 2: Describe your problem

Attemting to use gef to step (si) through a program unexpectedly aborts at the end of program with the following error:

 ─────[ threads ]────
[#0] Id 1, Name: "sp_demo", stopped, reason: SINGLE STEP    
─────[ trace ]────
[#0] 0x10064 → Name: exit()
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted

This behavior is not observed when using peda or pwndbg, which exit normally. This behavior is not observed when just running program:

Reading symbols from sp_demo...(no debugging symbols found)...done.
gef➤  run
Starting program: /home/timmy/ARM/code/sp_demo 
[Inferior 1 (process 2528) exited normally]
gef➤

Steps to reproduce

gdb -q sp_demo
gef> b _start
gef> r
gef> si (until error observed)

Observed Results

See above.

Expected results

 f 0    10068 exit+4
pwndbg> si
[Inferior 1 (process 2545) exited normally]
pwndbg>

Sample code, sp_demo

@ Test code, stack pointer example 

    .global _start

_start:
   mov r7, #0x30      
   push {r7}          
   mov r7, #0x10      
   pop {r7}           

exit:
    mov r7, #1       
    svc 0

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 16 (6 by maintainers)

Commits related to this issue

[issue #206] updated the faq to explain the case of the mysterious gdb_exception_RETURN_MASK_ERROR assert on ARM — committed to hugsy/gef by deleted user 6 years ago
[issue #206] updated the faq to explain the case of the mysterious gdb_exception_RETURN_MASK_ERROR assert on ARM — committed to SakiiR/gef by deleted user 6 years ago

Most upvoted comments

For those who find “build gdb from sources” to be insufficient detail, here is what worked for me today:

wget "https://ftp.gnu.org/gnu/gdb/gdb-8.2.tar.gz"
tar -xvzf gdb-8.2.tar.gz
cd gdb-8.2/
./configure --with-python
make
sudo make install

The thing missing from other instructions is that configure needs to be with python. Without it you get #402.

jgfoster on Dec 6, 2018

@hugsy : I’ve confirmed on my end @sashs comment and @Sinkmanu’s result. I believe this issue can be closed.

Original Issue and Mitigation

gdb version 7.12, as distributed w/ Raspbian/Kali rolling (only distro’s tested,) throws an exception while disassembling ARM binaries when using gef. This is not a gef problem, this is a gdb problem. gef is just the tool that revealed the gdb dain bramage! (The issue was not observed using vanilla gdb/peda/pwndbg) This issue was first noted when using si to step through a simple ARM assembly program (noted above) when instead of exiting cleanly, gdb’s disassembly failed with a SIGABRT and threw an exception:

  gdb_exception_RETURN_MASK_ERROR

This turns out to be a known problem (regression) with gdb, and affects gef users running the ARM platform (Raspberry Pi).

The mitigation is for ARM users to compile gdb from source and run the latest version, 8.1 as of this writing.

gef’s README.md should be changed to direct users of the ARM platform, or at least the Raspberry Pi, to ignore their distribution’s packaged version of gdb (assuming it is not current) and compile gdb from source.

feralgibbons on Feb 3, 2018

Hi. If I recall correctly, it is an issue in older versions of GDB (not the current version). It should be still an issue on Raspberrypi, since GDB 7.12 is the current version in the repositories of raspbian.

sashs on Feb 3, 2018

@feralgibbons @sashs @Sinkmanu Thanks for your tests and feedbacks.

I will document this behavior based on @feralgibbons’ last comment for others to know about it.

Cheers.

hugsy on Feb 4, 2018

@Sinkmanu It is a GDB-issued exception, nothing to do with GEF. Also just saying “I have the same problem” is not helpful to fix it. In the future, try to provide more info (your setup, the binary you were testing that on, etc.)

@sashs reported me privately a very same issue not long ago. Apparently the issue would come from GDB triggering this assert() when disassembly an invalid memory area.

I will try to reproduce it, but in any case, there is very little GEF can do about it. This issue should be propagated to the GDB developers.

hugsy on Feb 3, 2018

@Sinkmanu: Pretty sure that this is indeed a gdb issue.

It looks like perhaps we’re both using Pi’s? Mine’s a 3B, and the latest gdb source I can get from my distro (Kali rolling – using ‘apt-get source gdb’) is 7.12.0.20161007. I’m going to try something else here and see if I get any joy, but it’s going to take a bit.

feralgibbons on Feb 3, 2018

That’s a GDB error, not GEF. This is not even even related to GDB’s Python API. You might wanna check forums or ask on their IRC.

hugsy on Jan 31, 2018