SEGFAULT when stepping in V! #13120
Comments
|
Can you build with asan and paste the crashlog? Sys/asan.sh or just attach gdb/lldb and paste bt, regstate etc
… On 15 Feb 2019, at 21:19, bannsec ***@***.***> wrote:
Work environment
Questions Answers
OS/arch/bits (mandatory) Ubuntu x86 64
File format of the file you reverse (mandatory) ELF
Architecture/bits of the file (mandatory) x86/64
r2 -v full output, not truncated (mandatory) radare2 3.3.0-git 81 @ linux-x86-64 git.3.3.0-git commit: 69ed848 build: 2019-02-13__23:04:54
Expected behavior
Successfully be able to step in V! mode.
Actual behavior
Segfault
Steps to reproduce the behavior
r2 -A ./known_values
ood
db main
dc
V!
F8
Segfault
Additional Logs, screenshots, source-code, configuration dump, ...
This does not seem to happen if i don't add the -A in the load line.
known_values.zip
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Re-compiled with asan like you mentioned, but couldn't even open up r2 now: |
|
Its crashing because of the angr plugin. Delete it. Or rebuild it
… On 15 Feb 2019, at 23:05, bannsec ***@***.***> wrote:
Re-compiled with asan like you mentioned, but couldn't even open up r2 now:
/usr/bin/r2 -A ./known_values_x64
=================================================================
==49260==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61a000b36f70 at pc 0x7f1f2f6f6733 bp 0x7ffd045ec680 sp 0x7ffd045ebe28
READ of size 1272 at 0x61a000b36f70 thread T0
#0 0x7f1f2f6f6732 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
#1 0x7f1f2e9106ab in __lib_io_cb /home/angr/opt/radare2/libr/core/libs.c:30
#2 0x7f1f2598c8d1 in r_lib_run_handler /home/angr/opt/radare2/libr/util/lib.c:175
#3 0x7f1f2598e32a in r_lib_open_ptr /home/angr/opt/radare2/libr/util/lib.c:325
#4 0x7f1f1f3616c9 in Radare_plugin_io python/io.c:214
#5 0x7f1f1f35ffa4 in Radare_plugin /home/angr/.local/share/radare2/r2pm/git/radare2-bindings/libr/lang/p/python.c:156
#6 0x7f1f1eeb29ea in _PyCFunction_FastCallDict (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x2139ea)
#7 0x7f1f1ee1ae0b (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x17be0b)
#8 0x7f1f1ee21091 in _PyEval_EvalFrameDefault (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x182091)
#9 0x7f1f1ee1a63e (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x17b63e)
#10 0x7f1f1ee1b0fd in PyEval_EvalCodeEx (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x17c0fd)
#11 0x7f1f1ee1bfda in PyEval_EvalCode (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x17cfda)
#12 0x7f1f1eded011 in PyRun_FileExFlags (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x14e011)
#13 0x7f1f1edee41c in PyRun_SimpleFileExFlags (/usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0+0x14f41c)
#14 0x7f1f1f360040 in slurp_python /home/angr/.local/share/radare2/r2pm/git/radare2-bindings/libr/lang/p/python.c:105
#15 0x7f1f1f360040 in run_file /home/angr/.local/share/radare2/r2pm/git/radare2-bindings/libr/lang/p/python.c:113
#16 0x7f1f23b3013f in r_lang_run_file /home/angr/opt/radare2/libr/lang/lang.c:223
#17 0x7f1f2e87ecc3 in lang_run_file /home/angr/opt/radare2/libr/core/cmd.c:720
#18 0x7f1f2e87f3dc in r_core_run_script /home/angr/opt/radare2/libr/core/cmd.c:755
#19 0x7f1f2e88095f in cmd_interpret /home/angr/opt/radare2/libr/core/cmd.c:925
#20 0x7f1f2e9a1c44 in r_cmd_call /home/angr/opt/radare2/libr/core/cmd_api.c:235
#21 0x7f1f2e8944fa in r_core_cmd_subst_i /home/angr/opt/radare2/libr/core/cmd.c:3012
#22 0x7f1f2e889bf9 in r_core_cmd_subst /home/angr/opt/radare2/libr/core/cmd.c:2021
#23 0x7f1f2e89c4e8 in r_core_cmd /home/angr/opt/radare2/libr/core/cmd.c:3746
#24 0x7f1f2e89d50c in r_core_cmdf /home/angr/opt/radare2/libr/core/cmd.c:3905
#25 0x7f1f2e911e17 in r_core_loadlibs /home/angr/opt/radare2/libr/core/libs.c:115
#26 0x5614b437fff8 in main /home/angr/opt/radare2/binr/radare2/radare2.c:861
#27 0x7f1f24527b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#28 0x5614b437b909 in _start (/home/angr/opt/radare2/binr/radare2/radare2+0x10909)
0x61a000b36f70 is located 0 bytes to the right of 1264-byte region [0x61a000b36a80,0x61a000b36f70)
allocated by thread T0 here:
#0 0x7f1f2f75bd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
#1 0x7f1f1f361545 in Radare_plugin_io python/io.c:164
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
Shadow bytes around the buggy address:
0x0c348015ed90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015eda0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015edb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015edc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015edd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c348015ede0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa
0x0c348015edf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c348015ee00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c348015ee10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015ee20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c348015ee30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==49260==ABORTING
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Ok, guessing this is the relevant lines: Full errors are in the attached file. Whole bunch of Memory Leak traces in it. Unfortunately, no backtrace was printed. |
|
I have a fix for this unaligned issue in the alloc branch. But i doubt thats the reason of the crash
… On 16 Feb 2019, at 01:44, bannsec ***@***.***> wrote:
Ok, guessing this is the relevant lines:
12 ^[[?1001r^[[?1000lp/io_ptrace.c:64:10: runtime error: store to misaligned address 0x7ffd09705c51 for type 'unsigned int', which requires 4 byte alignment
13 0x7ffd09705c51: note: pointer points here
14 7f 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
15 ^
16 child stopped with signal 11
17 [+] SIGNAL 11 errno=0 addr=0x00177ff8 code=1 ret=0
18 child stopped with signal 11
19 [+] SIGNAL 11 errno=0 addr=0x00177ff8 code=1 ret=0
20 child stopped with signal 11
21 [+] SIGNAL 11 errno=0 addr=0x00177ff8 code=1 ret=0
22 child stopped with signal 11
23 [+] SIGNAL 11 errno=0 addr=0x00177ff8 code=1 ret=0
Full errors are in the attached file. Whole bunch of Memory Leak traces in it.
errors.zip
Unfortunately, no backtrace was printed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Trying it with the new branch, r2 SEGFAULTs on That happens with or without the |
|
Probably because of the dL segfault issue
… On 16 Feb 2019, at 18:06, bannsec ***@***.***> wrote:
Trying it with the new branch, r2 SEGFAULTs on ood now, so before I can get to the original issue.
r2 -A ./x86_64/known_values_x64
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[x] Type matching analysis for all functions (aaft)
[x] Use -AA or aaaa to perform additional experimental analysis.
-- You crackme up!
[0x00401040]> ood
Process with PID 35502 started...
File dbg:///home/angr/angr-dev/binaries/tests/x86_64/known_values_x64 reopened in read-write mode
= attach 35502 35502
ASAN:DEADLYSIGNAL
=================================================================
==35500==ERROR: AddressSanitizer: SEGV on unknown address 0x611ffffffff8 (pc 0x7f84adef0784 bp 0x7ffc08d470c0 sp 0x7ffc08d47080 T0)
==35500==The signal is caused by a WRITE memory access.
AddressSanitizer: nested bug in the same thread, aborting.
That happens with or without the -A option. Here's a gdb backtrace:
0x00007f27bf3964ff in r_malloc_aligned (size=256, alignment=4294967295) at alloc.c:68
(gdb) bt#0 0x00007f27bf3964ff in r_malloc_aligned (size=256, alignment=4294967295) at alloc.c:68
#1 0x00007f27c0e44124 in __read (io=0x555e5d5fdd80, desc=0x555e5d7bd880, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at p/io_ptrace.c:104
#2 0x00007f27c0e51b24 in r_io_plugin_read (desc=0x555e5d7bd880, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at plugin.c:165
#3 0x00007f27c0e54367 in r_io_desc_read (desc=0x555e5d7bd880, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at desc.c:192
#4 0x00007f27c0e549b7 in r_io_desc_read_at (desc=0x555e5d7bd880, addr=140435284934800, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at desc.c:324
#5 0x00007f27c0e500af in r_io_pread_at (io=0x555e5d5fdd80, paddr=140435284934800, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at io.c:274
#6 0x00007f27c0e502dd in r_io_read_at (io=0x555e5d5fdd80, addr=140435284934800, buf=0x555e5d5a9320 '\377' <repeats 200 times>..., len=256) at io.c:307
#7 0x00007f27c0a57def in r_core_block_read (core=0x555e5bddd1c0 <r>) at cio.c:418
#8 0x00007f27c0a579a0 in r_core_seek (core=0x555e5bddd1c0 <r>, addr=140435284934800, rb=true) at cio.c:293
#9 0x00007f27c09ff7f0 in seek_to_register (core=0x555e5bddd1c0 <r>, input=0x555e5d6a6273 "PC", is_silent=false) at cmd_seek.c:206
#10 0x00007f27c09fff9f in cmd_seek (data=0x555e5bddd1c0 <r>, input=0x555e5d6a6271 "r PC") at cmd_seek.c:343
#11 0x00007f27c0a82ca9 in r_cmd_call (cmd=0x555e5d611fd0, input=0x555e5d6a6270 "sr PC") at cmd_api.c:235
#12 0x00007f27c0a3393a in r_core_cmd_subst_i (core=0x555e5bddd1c0 <r>, cmd=0x555e5d6a6270 "sr PC", colon=0x0, tmpseek=0x7ffd1ad69bc2) at cmd.c:3012
#13 0x00007f27c0a30378 in r_core_cmd_subst (core=0x555e5bddd1c0 <r>, cmd=0x555e5d6a6270 "sr PC") at cmd.c:2021
#14 0x00007f27c0a36048 in r_core_cmd (core=0x555e5bddd1c0 <r>, cstr=0x7f27c0b1964a "sr PC", log=0) at cmd.c:3746
#15 0x00007f27c0a56c18 in r_core_setup_debugger (r=0x555e5bddd1c0 <r>, debugbackend=0x7f27c0b0e28a "native", attach=true) at cio.c:43
#16 0x00007f27c0a3852e in r_core_file_reopen (core=0x555e5bddd1c0 <r>, args=0x555e5d803b90 "\340Q\200]^U", perm=7, loadbin=2) at cfile.c:124
#17 0x00007f27c09ecbc0 in r_core_file_reopen_debug (core=0x555e5bddd1c0 <r>, args=0x555e5d7dad53 "") at cmd_open.c:891
#18 0x00007f27c09ee93a in cmd_open (data=0x555e5bddd1c0 <r>, input=0x555e5d7dad51 "od") at cmd_open.c:1423
#19 0x00007f27c0a82ca9 in r_cmd_call (cmd=0x555e5d611fd0, input=0x555e5d7dad50 "ood") at cmd_api.c:235
#20 0x00007f27c0a3393a in r_core_cmd_subst_i (core=0x555e5bddd1c0 <r>, cmd=0x555e5d7dad50 "ood", colon=0x0, tmpseek=0x7ffd1ad6a352) at cmd.c:3012
#21 0x00007f27c0a30378 in r_core_cmd_subst (core=0x555e5bddd1c0 <r>, cmd=0x555e5d7dad50 "ood") at cmd.c:2021
#22 0x00007f27c0a36048 in r_core_cmd (core=0x555e5bddd1c0 <r>, cstr=0x555e5d7ebc40 "ood", log=1) at cmd.c:3746
#23 0x00007f27c09940c7 in r_core_prompt_exec (r=0x555e5bddd1c0 <r>) at core.c:2749
#24 0x0000555e5bdd81b6 in main (argc=2, argv=0x7ffd1ad6a858, envp=0x7ffd1ad6a870) at radare2.c:1484
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
can you try again? |
|
Both master branch and alloc branch fail to step still. However, I'm having a hard time getting asan to print anything useful. One thing I have noticed is that the highlighted 'current instruction' in Here are two strange behaviors: SEGFAULT stepping:
OK Stepping
|
|
Also, some error pops up behind the visual panels. I've only been able to catch a portion of it: |
|
cant repro |
|
I can reproduce on a fully clean base radare2 docker build (pulled just now), as below: The Segfault will show at the bottom of the V! panel screen. |
|
What about doing the same with asan so we can see a useful backtrace and do a blindfix?
… On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
I can reproduce on a fully clean base radare2 docker build (pulled just now), as below:
The Segfault will show at the bottom of the V! panel screen.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
ehmm... the crash is for the target app, not for r2, right?
… On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
I can reproduce on a fully clean base radare2 docker build (pulled just now), as below:
<https://asciinema.org/a/0y8FoDivXxLTz6ufRHFw3L4r0>
The Segfault will show at the bottom of the V! panel screen.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13120 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-lkwR7NyB0aOgmoO9vlS9QdBTZnptks5vO4t1gaJpZM4a-XOb>.
|
|
Not what the cause of the crash is. The issue is that single stepping one
instruction in visual panel causes that segfault issue while the same
single step at the same point outside of the visual panel does not.
Come to think of it, it looks like the panel mode is simply not setting the
appropriate breakpoint, allowing the program to continue instead of single
step.
I can make another video showing how normal step works fine if that would
be helpful.
…On Tue, Feb 19, 2019, 5:23 AM radare ***@***.*** wrote:
ehmm... the crash is for the target app, not for r2, right?
> On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
>
> I can reproduce on a fully clean base radare2 docker build (pulled just
now), as below:
>
> <https://asciinema.org/a/0y8FoDivXxLTz6ufRHFw3L4r0>
> The Segfault will show at the bottom of the V! panel screen.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <
#13120 (comment)>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AA3-lkwR7NyB0aOgmoO9vlS9QdBTZnptks5vO4t1gaJpZM4a-XOb
>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13120 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHR34Mwl8TdQz8CQlDw0vYIPz05G3N_qks5vO9CUgaJpZM4a-XOb>
.
|
|
so the one crashing is the debugged process, not r2, right?
… On 19 Feb 2019, at 15:20, bannsec ***@***.***> wrote:
Not what the cause of the crash is. The issue is that single stepping one
instruction in visual panel causes that segfault issue while the same
single step at the same point outside of the visual panel does not.
Come to think of it, it looks like the panel mode is simply not setting the
appropriate breakpoint, allowing the program to continue instead of single
step.
I can make another video showing how normal step works fine if that would
be helpful.
On Tue, Feb 19, 2019, 5:23 AM radare ***@***.*** wrote:
> ehmm... the crash is for the target app, not for r2, right?
>
> > On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
> >
> > I can reproduce on a fully clean base radare2 docker build (pulled just
> now), as below:
> >
> > <https://asciinema.org/a/0y8FoDivXxLTz6ufRHFw3L4r0>
> > The Segfault will show at the bottom of the V! panel screen.
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub <
> #13120 (comment)>,
> or mute the thread <
> https://github.com/notifications/unsubscribe-auth/AA3-lkwR7NyB0aOgmoO9vlS9QdBTZnptks5vO4t1gaJpZM4a-XOb
> >.
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#13120 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AHR34Mwl8TdQz8CQlDw0vYIPz05G3N_qks5vO9CUgaJpZM4a-XOb>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13120 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-ls_9ezohBDJCgms-s0wsLuUIztr3ks5vPAgUgaJpZM4a-XOb>.
|
|
I'm guessing that's the case. Still would like to be able to single step in
panel mode though
…On Tue, Feb 19, 2019, 9:21 AM radare ***@***.*** wrote:
so the one crashing is the debugged process, not r2, right?
> On 19 Feb 2019, at 15:20, bannsec ***@***.***> wrote:
>
> Not what the cause of the crash is. The issue is that single stepping one
> instruction in visual panel causes that segfault issue while the same
> single step at the same point outside of the visual panel does not.
>
> Come to think of it, it looks like the panel mode is simply not setting
the
> appropriate breakpoint, allowing the program to continue instead of
single
> step.
>
> I can make another video showing how normal step works fine if that would
> be helpful.
>
> On Tue, Feb 19, 2019, 5:23 AM radare ***@***.*** wrote:
>
> > ehmm... the crash is for the target app, not for r2, right?
> >
> > > On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
> > >
> > > I can reproduce on a fully clean base radare2 docker build (pulled
just
> > now), as below:
> > >
> > > <https://asciinema.org/a/0y8FoDivXxLTz6ufRHFw3L4r0>
> > > The Segfault will show at the bottom of the V! panel screen.
> > >
> > > —
> > > You are receiving this because you commented.
> > > Reply to this email directly, view it on GitHub <
> > #13120 (comment)
>,
> > or mute the thread <
> >
https://github.com/notifications/unsubscribe-auth/AA3-lkwR7NyB0aOgmoO9vlS9QdBTZnptks5vO4t1gaJpZM4a-XOb
> > >.
> > >
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <#13120 (comment)
>,
> > or mute the thread
> > <
https://github.com/notifications/unsubscribe-auth/AHR34Mwl8TdQz8CQlDw0vYIPz05G3N_qks5vO9CUgaJpZM4a-XOb
>
> > .
> >
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <
#13120 (comment)>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AA3-ls_9ezohBDJCgms-s0wsLuUIztr3ks5vPAgUgaJpZM4a-XOb
>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13120 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHR34IvmfVSRj83RhVhijHVjfbgbDGOUks5vPAhkgaJpZM4a-XOb>
.
|
|
ok, i just wanted to clarify the issue because i was expecting r2 to crash but its not. yes thats an issue and should be fixed
thanks for reporting
… On 19 Feb 2019, at 15:22, bannsec ***@***.***> wrote:
I'm guessing that's the case. Still would like to be able to single step in
panel mode though
On Tue, Feb 19, 2019, 9:21 AM radare ***@***.*** wrote:
> so the one crashing is the debugged process, not r2, right?
>
> > On 19 Feb 2019, at 15:20, bannsec ***@***.***> wrote:
> >
> > Not what the cause of the crash is. The issue is that single stepping one
> > instruction in visual panel causes that segfault issue while the same
> > single step at the same point outside of the visual panel does not.
> >
> > Come to think of it, it looks like the panel mode is simply not setting
> the
> > appropriate breakpoint, allowing the program to continue instead of
> single
> > step.
> >
> > I can make another video showing how normal step works fine if that would
> > be helpful.
> >
> > On Tue, Feb 19, 2019, 5:23 AM radare ***@***.*** wrote:
> >
> > > ehmm... the crash is for the target app, not for r2, right?
> > >
> > > > On 19 Feb 2019, at 06:28, bannsec ***@***.***> wrote:
> > > >
> > > > I can reproduce on a fully clean base radare2 docker build (pulled
> just
> > > now), as below:
> > > >
> > > > <https://asciinema.org/a/0y8FoDivXxLTz6ufRHFw3L4r0>
> > > > The Segfault will show at the bottom of the V! panel screen.
> > > >
> > > > —
> > > > You are receiving this because you commented.
> > > > Reply to this email directly, view it on GitHub <
> > > #13120 (comment)
> >,
> > > or mute the thread <
> > >
> https://github.com/notifications/unsubscribe-auth/AA3-lkwR7NyB0aOgmoO9vlS9QdBTZnptks5vO4t1gaJpZM4a-XOb
> > > >.
> > > >
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <#13120 (comment)
> >,
> > > or mute the thread
> > > <
> https://github.com/notifications/unsubscribe-auth/AHR34Mwl8TdQz8CQlDw0vYIPz05G3N_qks5vO9CUgaJpZM4a-XOb
> >
> > > .
> > >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub <
> #13120 (comment)>,
> or mute the thread <
> https://github.com/notifications/unsubscribe-auth/AA3-ls_9ezohBDJCgms-s0wsLuUIztr3ks5vPAgUgaJpZM4a-XOb
> >.
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#13120 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AHR34IvmfVSRj83RhVhijHVjfbgbDGOUks5vPAhkgaJpZM4a-XOb>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13120 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-ln1xptvAWpKahf64SA-KS8rT9mKLks5vPAidgaJpZM4a-XOb>.
|
radare
added
panel
|
ping @Vane11ope is this fixed? cc @bannsec |
|
i think this shoul dbe fixed now, the problem wwas with symbol visibility and multiple versions of python, reopen if not |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Work environment
Expected behavior
Successfully be able to step in
V!mode.Actual behavior
Segfault
Steps to reproduce the behavior
Additional Logs, screenshots, source-code, configuration dump, ...
This does not seem to happen if i don't add the -A in the load line.
known_values.zip
The text was updated successfully, but these errors were encountered: