gdb:// connection segfault for ARM #1560

XVilka · 2014-10-23T13:05:44Z

gdb$ run -a arm -b 32 -d -D gdb -e io.va=true gdb://127.0.0.1:1234
Starting program: /usr/bin/r2 -a arm -b 32 -d -D gdb -e io.va=true gdb://127.0.0.1:1234
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
r_debug_select: 6 6
pid = 7167264 tid = 1
r_debug_select: 7167264 1

Program received signal SIGSEGV, Segmentation fault.
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x0000000000000000  RBP: 0x00007FFFFFFFB350  RSP: 0x00007FFFFFFFB280  o d I t s z a p c 
  RDI: 0x00000000006DDCA8  RSI: 0x00000000006D7ED8  RDX: 0x400001D300000000  RCX: 0x00000000000000A8  RIP: 0x00007FFFF6DE8B60
  R8 : 0x0000000000000068  R9 : 0x0101010101010101  R10: 0x00007FFFFFFFAFF0  R11: 0x00007FFFF4132C50  R12: 0x00007FFFFFFFB2F0
  R13: 0x00007FFFFFFFDA60  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B                
-----------------------------------------------------------------------------------------------------------------------[code]
=> 0x7ffff6de8b60 <r_debug_reg_sync+512>:   mov    0x38(%rax),%rax
   0x7ffff6de8b64 <r_debug_reg_sync+516>:   mov    -0x14(%rbp),%esi
   0x7ffff6de8b67 <r_debug_reg_sync+519>:   mov    %rax,%rdi
   0x7ffff6de8b6a <r_debug_reg_sync+522>:   callq  0x7ffff6de48c0 <r_reg_set_bytes@plt>
   0x7ffff6de8b6f <r_debug_reg_sync+527>:   mov    $0x1,%eax
   0x7ffff6de8b74 <r_debug_reg_sync+532>:   mov    %r12,%rsp
   0x7ffff6de8b77 <r_debug_reg_sync+535>:   cmp    $0x1,%eax
   0x7ffff6de8b7a <r_debug_reg_sync+538>:   jne    0x7ffff6de8b9a <r_debug_reg_sync+570>
-----------------------------------------------------------------------------------------------------------------------------
0x00007ffff6de8b60 in r_debug_reg_sync (dbg=0x0, type=0x0, write=0x0) at reg.c:41
41              r_reg_set_bytes (dbg->reg, i, buf, size);
gdb$ bt
#0  0x00007ffff6de8b60 in r_debug_reg_sync (dbg=0x0, type=0x0, write=0x0) at reg.c:41
#1  0x00007ffff7b3f95d in cmd_debug_reg (core=0x607540 <r>, str=0x6c9592 "*") at cmd_debug.c:721
#2  0x00007ffff7b423cd in cmd_debug (data=0x607540 <r>, input=0x6c9591 "r*") at cmd_debug.c:1480
#3  0x00007ffff7b8ce24 in r_cmd_call (cmd=0x6a8980, input=0x6c9590 "dr*") at cmd_api.c:179
#4  0x00007ffff7b6d43a in r_core_cmd_subst_i (core=0x607540 <r>, cmd=0x6c9590 "dr*") at cmd.c:1251
#5  0x00007ffff7b6bb98 in r_core_cmd_subst (core=0x607540 <r>, cmd=0x6c9590 "dr*") at cmd.c:804
#6  0x00007ffff7b6df5d in r_core_cmd (core=0x607540 <r>, cstr=0x6d7770 "dr*", log=0x0) at cmd.c:1449
#7  0x00007ffff7b6e77c in r_core_cmd_str (core=0x607540 <r>, cmd=0x6d7770 "dr*") at cmd.c:1622
#8  0x00007ffff7b6a80e in cmd_interpret (data=0x607540 <r>, input=0x6c9601 "dr*") at cmd.c:379
#9  0x00007ffff7b8ce24 in r_cmd_call (cmd=0x6a8980, input=0x6c9600 ".dr*") at cmd_api.c:179
#10 0x00007ffff7b6d43a in r_core_cmd_subst_i (core=0x607540 <r>, cmd=0x6c9600 ".dr*") at cmd.c:1251
#11 0x00007ffff7b6bb98 in r_core_cmd_subst (core=0x607540 <r>, cmd=0x6c9600 ".dr*") at cmd.c:804
#12 0x00007ffff7b6df5d in r_core_cmd (core=0x607540 <r>, cstr=0x7ffff7bc15fd ".dr*", log=0x0) at cmd.c:1449
#13 0x00007ffff7b7bcaa in r_core_setup_debugger (r=0x607540 <r>, debugbackend=0x7fffffffde28 "gdb") at io.c:22
#14 0x0000000000404b20 in main (argc=0xb, argv=0x7fffffffda68, envp=0x7fffffffdac8) at radare2.c:591
gdb$

The text was updated successfully, but these errors were encountered:

radare · 2014-10-23T13:11:40Z

dbg shouldnt be null there. try with valgrind, maybe its overflowing and
filling the pointer
On 10/23/2014 03:05 PM, Anton Kochkov wrote:

|gdb$ run -a arm -b 32 -d -D gdb -e io.va=true gdb://127.0.0.1:1234
Starting program: /usr/bin/r2 -a arm -b 32 -d -D gdb -e io.va=true gdb://127.0.0.1:1234
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
r_debug_select: 6 6
pid = 7167264 tid = 1
r_debug_select: 7167264 1

Program received signal SIGSEGV, Segmentation fault.
-----------------------------------------------------------------------------------------------------------------------[regs]
RAX: 0x0000000000000000 RBX: 0x0000000000000000 RBP: 0x00007FFFFFFFB350 RSP: 0x00007FFFFFFFB280 o d I t s z a p c
RDI: 0x00000000006DDCA8 RSI: 0x00000000006D7ED8 RDX: 0x400001D300000000 RCX: 0x00000000000000A8 RIP: 0x00007FFFF6DE8B60
R8 : 0x0000000000000068 R9 : 0x0101010101010101 R10: 0x00007FFFFFFFAFF0 R11: 0x00007FFFF4132C50 R12: 0x00007FFFFFFFB2F0
R13: 0x00007FFFFFFFDA60 R14: 0x0000000000000000 R15: 0x0000000000000000
CS: 0033 DS: 0000 ES: 0000 FS: 0000 GS: 0000 SS: 002B
-----------------------------------------------------------------------------------------------------------------------[code]
=> 0x7ffff6de8b60 <r_debug_reg_sync+512>: mov 0x38(%rax),%rax
0x7ffff6de8b64 <r_debug_reg_sync+516>: mov -0x14(%rbp),%esi
0x7ffff6de8b67 <r_debug_reg_sync+519>: mov %rax,%rdi
0x7ffff6de8b6a <r_debug_reg_sync+522>: callq 0x7ffff6de48c0 r_reg_set_bytes@plt
0x7ffff6de8b6f <r_debug_reg_sync+527>: mov $0x1,%eax
0x7ffff6de8b74 <r_debug_reg_sync+532>: mov %r12,%rsp
0x7ffff6de8b77 <r_debug_reg_sync+535>: cmp $0x1,%eax

0x7ffff6de8b7a <r_debug_reg_sync+538>: jne 0x7ffff6de8b9a <r_debug_reg_sync+570>

0x00007ffff6de8b60 in r_debug_reg_sync (dbg=0x0, type=0x0, write=0x0) at reg.c:41
41 r_reg_set_bytes (dbg->reg, i, buf, size);
gdb$ bt
#0 0x00007ffff6de8b60 in r_debug_reg_sync (dbg=0x0, type=0x0, write=0x0) at reg.c:41
#1 0x00007ffff7b3f95d in cmd_debug_reg (core=0x607540 , str=0x6c9592 "") at cmd_debug.c:721
#2 0x00007ffff7b423cd in cmd_debug (data=0x607540 , input=0x6c9591 "r") at cmd_debug.c:1480
#3 0x00007ffff7b8ce24 in r_cmd_call (cmd=0x6a8980, input=0x6c9590 "dr_") at cmd_api.c:179
#4 0x00007ffff7b6d43a in r_core_cmd_subst_i (core=0x607540 , cmd=0x6c9590 "dr_") at cmd.c:1251
#5 0x00007ffff7b6bb98 in r_core_cmd_subst (core=0x607540 , cmd=0x6c9590 "dr_") at cmd.c:804
#6 0x00007ffff7b6df5d in r_core_cmd (core=0x607540 , cstr=0x6d7770 "dr_", log=0x0) at cmd.c:1449
#7 0x00007ffff7b6e77c in r_core_cmd_str (core=0x607540 , cmd=0x6d7770 "dr_") at cmd.c:1622
#8 0x00007ffff7b6a80e in cmd_interpret (data=0x607540 , input=0x6c9601 "dr_") at cmd.c:379
#9 0x00007ffff7b8ce24 in r_cmd_call (cmd=0x6a8980, input=0x6c9600 ".dr_") at cmd_api.c:179
#10 0x00007ffff7b6d43a in r_core_cmd_subst_i (core=0x607540 , cmd=0x6c9600 ".dr_") at cmd.c:1251
#11 0x00007ffff7b6bb98 in r_core_cmd_subst (core=0x607540 , cmd=0x6c9600 ".dr_") at cmd.c:804
#12 0x00007ffff7b6df5d in r_core_cmd (core=0x607540 , cstr=0x7ffff7bc15fd ".dr_", log=0x0) at cmd.c:1449
#13 0x00007ffff7b7bcaa in r_core_setup_debugger (r=0x607540 , debugbackend=0x7fffffffde28 "gdb") at io.c:22
#14 0x0000000000404b20 in main (argc=0xb, argv=0x7fffffffda68, envp=0x7fffffffdac8) at radare2.c:591
gdb$
|

—
Reply to this email directly or view it on GitHub
#1560.

XVilka · 2014-10-23T13:17:24Z

@radare

==8767== Memcheck, a memory error detector
==8767== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8767== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==8767== Command: r2 -a arm -b 32 -d -D gdb -e io.va=true gdb://127.0.0.1:1234
==8767== 
r_debug_select: 6 6
pid = 160295840 tid = 1
r_debug_select: 160295840 1
==8767== Invalid read of size 8
==8767==    at 0x5C26B60: r_debug_reg_sync (reg.c:41)
==8767==    by 0x4E6A95C: cmd_debug_reg (cmd_debug.c:721)
==8767==    by 0x4E6D3CC: cmd_debug (cmd_debug.c:1480)
==8767==    by 0x4EB7E23: r_cmd_call (cmd_api.c:179)
==8767==    by 0x4E98439: r_core_cmd_subst_i (cmd.c:1251)
==8767==    by 0x4E96B97: r_core_cmd_subst (cmd.c:804)
==8767==    by 0x4E98F5C: r_core_cmd (cmd.c:1449)
==8767==    by 0x4E9977B: r_core_cmd_str (cmd.c:1622)
==8767==    by 0x4E9580D: cmd_interpret (cmd.c:379)
==8767==    by 0x4EB7E23: r_cmd_call (cmd_api.c:179)
==8767==    by 0x4E98439: r_core_cmd_subst_i (cmd.c:1251)
==8767==    by 0x4E96B97: r_core_cmd_subst (cmd.c:804)
==8767==  Address 0x38 is not stack'd, malloc'd or (recently) free'd
==8767== 
==8767== 
==8767== Process terminating with default action of signal 11 (SIGSEGV)
==8767==  Access not within mapped region at address 0x38
==8767==    at 0x5C26B60: r_debug_reg_sync (reg.c:41)
==8767==    by 0x4E6A95C: cmd_debug_reg (cmd_debug.c:721)
==8767==    by 0x4E6D3CC: cmd_debug (cmd_debug.c:1480)
==8767==    by 0x4EB7E23: r_cmd_call (cmd_api.c:179)
==8767==    by 0x4E98439: r_core_cmd_subst_i (cmd.c:1251)
==8767==    by 0x4E96B97: r_core_cmd_subst (cmd.c:804)
==8767==    by 0x4E98F5C: r_core_cmd (cmd.c:1449)
==8767==    by 0x4E9977B: r_core_cmd_str (cmd.c:1622)
==8767==    by 0x4E9580D: cmd_interpret (cmd.c:379)
==8767==    by 0x4EB7E23: r_cmd_call (cmd_api.c:179)
==8767==    by 0x4E98439: r_core_cmd_subst_i (cmd.c:1251)
==8767==    by 0x4E96B97: r_core_cmd_subst (cmd.c:804)
==8767==  If you believe this happened as a result of a stack
==8767==  overflow in your program's main thread (unlikely but
==8767==  possible), you can try to increase the size of the
==8767==  main thread stack using the --main-stacksize= flag.
==8767==  The main thread stack size used in this run was 8388608.
==8767== 
==8767== HEAP SUMMARY:
==8767==     in use at exit: 439,564 bytes in 2,418 blocks
==8767==   total heap usage: 6,576 allocs, 4,158 frees, 1,102,212 bytes allocated
==8767==

XVilka · 2014-10-23T13:18:56Z

And here is the full log http://xvilka.me/r2_val.log

XVilka · 2014-10-23T16:43:54Z

I've implemented ARM32 profile in e0b2055 but bug is still here :/ Here is the suite to replay the bug http://xvilka.me/bug.tar.bz2

radare · 2014-10-23T17:21:39Z

even with a crappy profile, r2 should not segfault. Now that ive finished
my training i'll have some time again for r2dev :)

let me know how can i reproduce this crash

thx

On 10/23/2014 06:43 PM, Anton Kochkov wrote:

I've implemented ARM32 profile in e0b2055
e0b2055
but bug is still here :/

—
Reply to this email directly or view it on GitHub
#1560 (comment).

XVilka · 2014-10-23T23:30:09Z

@radare as I said - just open the link http://xvilka.me/bug.tar.bz2 unpack it, and run "run_qemu.sh" first, then "connect_r2.sh"

radare · 2014-10-24T00:55:18Z

404

XVilka · 2014-10-24T02:12:21Z

@radare retry - now it works

radare · 2014-10-25T23:34:02Z

Should be fixed now

radare closed this as completed Oct 25, 2014

yossizap pushed a commit to yossizap/radare2 that referenced this issue Dec 30, 2019

Improve Color Theme Copy Feature (radareorg#1560)

822034b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gdb:// connection segfault for ARM #1560

gdb:// connection segfault for ARM #1560

XVilka commented Oct 23, 2014

radare commented Oct 23, 2014

0x7ffff6de8b7a <r_debug_reg_sync+538>: jne 0x7ffff6de8b9a <r_debug_reg_sync+570>

XVilka commented Oct 23, 2014

XVilka commented Oct 23, 2014

XVilka commented Oct 23, 2014

radare commented Oct 23, 2014

XVilka commented Oct 23, 2014

radare commented Oct 24, 2014

XVilka commented Oct 24, 2014

radare commented Oct 25, 2014

gdb:// connection segfault for ARM #1560

gdb:// connection segfault for ARM #1560

Comments

XVilka commented Oct 23, 2014

radare commented Oct 23, 2014

0x7ffff6de8b7a <r_debug_reg_sync+538>: jne 0x7ffff6de8b9a <r_debug_reg_sync+570>

XVilka commented Oct 23, 2014

XVilka commented Oct 23, 2014

XVilka commented Oct 23, 2014

radare commented Oct 23, 2014

XVilka commented Oct 23, 2014

radare commented Oct 24, 2014

XVilka commented Oct 24, 2014

radare commented Oct 25, 2014