Segfault when saving project after 'aac' #5219

axt · 2016-06-27T10:32:17Z

I've an exe for which the Ps command SEGFAULTs, after running aac.

Unfortunatelly I can't submit the binary. (+the aac runs 2 hours on this binary, so its not easy to test)

I've made a gdb backtrace, if that helps:
(seems strdup is called with a NULL pointer)

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) ba
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007f3df0c5b82e in __GI___strdup (s=0x0) at strdup.c:41
#2  0x00007f3df2e96572 in r_anal_var_list (a=0x7f3df4d6f180, fcn=0x7f3dfeb22910, kind=97) at var.c:472
#3  0x00007f3df2e9663f in r_anal_var_list_show (anal=0x7f3df4d6f180, fcn=0x7f3dfeb22910, kind=97, mode=42) at var.c:493
#4  0x00007f3df44dd381 in var_cmd (core=0x7f3df4bfb5c0 <r>, str=0x7f3dfdc19ce0 "a*") at cmd_anal.c:121
#5  0x00007f3df44e147d in cmd_anal_fcn (core=0x7f3df4bfb5c0 <r>, input=0x7f3dfdbc5151 "fa*") at cmd_anal.c:1081
#6  0x00007f3df44edb89 in cmd_anal (data=0x7f3df4bfb5c0 <r>, input=0x7f3dfdbc5151 "fa*") at cmd_anal.c:4455
#7  0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3dfdbc5150 "afa*") at cmd_api.c:210
#8  0x00007f3df451a31f in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3dfdbc5150 "afa*", colon=0x0) at cmd.c:1812
#9  0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3dfdbc5150 "afa*") at cmd.c:1249
#10 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 <r>, cstr=0x7fff8c1799f0 "afa* @ 0x56d68c\n", log=0) at cmd.c:2260
#11 0x00007f3df451c2bc in r_core_cmdf (user=0x7f3df4bfb5c0 <r>, fmt=0x7f3df45ab017 "afa* @ 0x%llx\n") at cmd.c:2391
#12 0x00007f3df4557b53 in fcn_print_detail (core=0x7f3df4bfb5c0 <r>, fcn=0x7f3dfeb22910) at anal.c:1646
#13 0x00007f3df4558169 in fcn_list_detail (core=0x7f3df4bfb5c0 <r>, fcns=0x7f3df4d85690) at anal.c:1721
#14 0x00007f3df4558443 in r_core_anal_fcn_list (core=0x7f3df4bfb5c0 <r>, input=0x0, rad=42) at anal.c:1781
#15 0x00007f3df44e1251 in cmd_anal_fcn (core=0x7f3df4bfb5c0 <r>, input=0x7f3df7501f31 "fl*") at cmd_anal.c:1043
#16 0x00007f3df44edb89 in cmd_anal (data=0x7f3df4bfb5c0 <r>, input=0x7f3df7501f31 "fl*") at cmd_anal.c:4455
#17 0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3df7501f30 "afl*") at cmd_api.c:210
#18 0x00007f3df451a55a in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3df7501f30 "afl*", colon=0x0) at cmd.c:1853
#19 0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3df7501f30 "afl*") at cmd.c:1249
#20 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 <r>, cstr=0x7f3df45ab84b "afl*", log=0) at cmd.c:2260
#21 0x00007f3df455d922 in r_core_project_save_rdb (core=0x7f3df4bfb5c0 <r>, file=0x7f3df73ca940 "/data/home/R2Projects/ispsoft2", opts=65503) at project.c:333
#22 0x00007f3df455dbe4 in r_core_project_save (core=0x7f3df4bfb5c0 <r>, file=0x7f3e247b0ee3 "ispsoft2") at project.c:397
#23 0x00007f3df44d4618 in cmd_project (data=0x7f3df4bfb5c0 <r>, input=0x7f3e247b0ee1 "s ispsoft2") at cmd_project.c:40
#24 0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3e247b0ee0 "Ps ispsoft2") at cmd_api.c:210
#25 0x00007f3df451a55a in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3e247b0ee0 "Ps ispsoft2", colon=0x0) at cmd.c:1853
#26 0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 <r>, cmd=0x7f3e247b0ee0 "Ps ispsoft2") at cmd.c:1249
#27 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 <r>, cstr=0x7f3df4d50050 "Ps ispsoft2", log=1) at cmd.c:2260
#28 0x00007f3df44c0249 in r_core_prompt_exec (r=0x7f3df4bfb5c0 <r>) at core.c:1624
#29 0x00007f3df49f8efe in main (argc=2, argv=0x7fff8c17d038, envp=0x7fff8c17d050) at radare2.c:943

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

radare · 2016-06-27T10:57:47Z

Its clearly a nullderef at var.c:472

On 27 Jun 2016, at 12:32, Attila Axt notifications@github.com wrote:

I've an exe for which the Ps command SEGFAULTs, after running aac.

Unfortunatelly I can't submit the binary. (+the aac runs 2 hours on this binary, so its not easy to test)

I've made a gdb backtrace, if that helps:
(seems strdup is called with a NULL pointer)

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) ba
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x00007f3df0c5b82e in GI___strdup (s=0x0) at strdup.c:41
#2 0x00007f3df2e96572 in r_anal_var_list (a=0x7f3df4d6f180, fcn=0x7f3dfeb22910, kind=97) at var.c:472
#3 0x00007f3df2e9663f in r_anal_var_list_show (anal=0x7f3df4d6f180, fcn=0x7f3dfeb22910, kind=97, mode=42) at var.c:493
#4 0x00007f3df44dd381 in var_cmd (core=0x7f3df4bfb5c0 , str=0x7f3dfdc19ce0 "a") at cmd_anal.c:121
#5 0x00007f3df44e147d in cmd_anal_fcn (core=0x7f3df4bfb5c0 , input=0x7f3dfdbc5151 "fa") at cmd_anal.c:1081
#6 0x00007f3df44edb89 in cmd_anal (data=0x7f3df4bfb5c0 , input=0x7f3dfdbc5151 "fa_") at cmd_anal.c:4455
#7 0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3dfdbc5150 "afa_") at cmd_api.c:210
#8 0x00007f3df451a31f in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 , cmd=0x7f3dfdbc5150 "afa_", colon=0x0) at cmd.c:1812
#9 0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 , cmd=0x7f3dfdbc5150 "afa_") at cmd.c:1249
#10 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 , cstr=0x7fff8c1799f0 "afa* @ 0x56d68c\n", log=0) at cmd.c:2260
#11 0x00007f3df451c2bc in r_core_cmdf (user=0x7f3df4bfb5c0 , fmt=0x7f3df45ab017 "afa* @ 0x%llx\n") at cmd.c:2391
#12 0x00007f3df4557b53 in fcn_print_detail (core=0x7f3df4bfb5c0 , fcn=0x7f3dfeb22910) at anal.c:1646
#13 0x00007f3df4558169 in fcn_list_detail (core=0x7f3df4bfb5c0 , fcns=0x7f3df4d85690) at anal.c:1721
#14 0x00007f3df4558443 in r_core_anal_fcn_list (core=0x7f3df4bfb5c0 , input=0x0, rad=42) at anal.c:1781
#15 0x00007f3df44e1251 in cmd_anal_fcn (core=0x7f3df4bfb5c0 , input=0x7f3df7501f31 "fl_") at cmd_anal.c:1043
#16 0x00007f3df44edb89 in cmd_anal (data=0x7f3df4bfb5c0 , input=0x7f3df7501f31 "fl_") at cmd_anal.c:4455
#17 0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3df7501f30 "afl_") at cmd_api.c:210
#18 0x00007f3df451a55a in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 , cmd=0x7f3df7501f30 "afl_", colon=0x0) at cmd.c:1853
#19 0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 , cmd=0x7f3df7501f30 "afl_") at cmd.c:1249
#20 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 , cstr=0x7f3df45ab84b "afl_", log=0) at cmd.c:2260
#21 0x00007f3df455d922 in r_core_project_save_rdb (core=0x7f3df4bfb5c0 , file=0x7f3df73ca940 "/data/home/R2Projects/ispsoft2", opts=65503) at project.c:333
#22 0x00007f3df455dbe4 in r_core_project_save (core=0x7f3df4bfb5c0 , file=0x7f3e247b0ee3 "ispsoft2") at project.c:397
#23 0x00007f3df44d4618 in cmd_project (data=0x7f3df4bfb5c0 , input=0x7f3e247b0ee1 "s ispsoft2") at cmd_project.c:40
#24 0x00007f3df45502c6 in r_cmd_call (cmd=0x7f3df4da2110, input=0x7f3e247b0ee0 "Ps ispsoft2") at cmd_api.c:210
#25 0x00007f3df451a55a in r_core_cmd_subst_i (core=0x7f3df4bfb5c0 , cmd=0x7f3e247b0ee0 "Ps ispsoft2", colon=0x0) at cmd.c:1853
#26 0x00007f3df4517eef in r_core_cmd_subst (core=0x7f3df4bfb5c0 , cmd=0x7f3e247b0ee0 "Ps ispsoft2") at cmd.c:1249
#27 0x00007f3df451bc87 in r_core_cmd (core=0x7f3df4bfb5c0 , cstr=0x7f3df4d50050 "Ps ispsoft2", log=1) at cmd.c:2260
#28 0x00007f3df44c0249 in r_core_prompt_exec (r=0x7f3df4bfb5c0 ) at core.c:1624
#29 0x00007f3df49f8efe in main (argc=2, argv=0x7fff8c17d038, envp=0x7fff8c17d050) at radare2.c:943
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

axt · 2016-06-27T11:21:50Z

I just wanted to note, that I've created this backtrace with @alvarofe -s pull request related to #5165, so the line numbers are valid in that version.

But the bug was present before of that. Here is an older backtrace I've saved a week ago (but don't know the exact version of it).

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106     ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) ba
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007f69d63b982e in __GI___strdup (s=0x0) at strdup.c:41
#2  0x00007f69d85f3021 in r_anal_var_list (a=0x7f69db4eb790, fcn=0x7f69e2f9e600, kind=97) at var.c:478
#3  0x00007f69d85f30ee in r_anal_var_list_show (anal=0x7f69db4eb790, fcn=0x7f69e2f9e600, kind=97, mode=42) at var.c:499
#4  0x00007f69d9c37057 in var_cmd (core=0x7f69da3545c0 <r>, str=0x7f69e2563270 "a*") at cmd_anal.c:121
#5  0x00007f69d9c3b08c in cmd_anal_fcn (core=0x7f69da3545c0 <r>, input=0x7f69e24b1551 "fa*") at cmd_anal.c:1058
#6  0x00007f69d9c4775a in cmd_anal (data=0x7f69da3545c0 <r>, input=0x7f69e24b1551 "fa*") at cmd_anal.c:4422
[...]

radare · 2016-06-27T11:41:06Z

var.c:478 is not a call to strdup..so my guess is that you are not using r2 from git. which version are you using?

On 27 Jun 2016, at 13:21, Attila Axt notifications@github.com wrote:

I just wanted to note, that I've created this backtrace with @alvarofe https://github.com/alvarofe -s pull request related to #5165 #5165, so the line numbers are valid in that version.

But the bug was present before of that. Here is an older backtrace I've saved a week ago (but don't know the exact version of it).

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) ba
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x00007f69d63b982e in GI___strdup (s=0x0) at strdup.c:41
#2 0x00007f69d85f3021 in r_anal_var_list (a=0x7f69db4eb790, fcn=0x7f69e2f9e600, kind=97) at var.c:478
#3 0x00007f69d85f30ee in r_anal_var_list_show (anal=0x7f69db4eb790, fcn=0x7f69e2f9e600, kind=97, mode=42) at var.c:499
#4 0x00007f69d9c37057 in var_cmd (core=0x7f69da3545c0 , str=0x7f69e2563270 "a") at cmd_anal.c:121
#5 0x00007f69d9c3b08c in cmd_anal_fcn (core=0x7f69da3545c0 , input=0x7f69e24b1551 "fa") at cmd_anal.c:1058
#6 0x00007f69d9c4775a in cmd_anal (data=0x7f69da3545c0 , input=0x7f69e24b1551 "fa*") at cmd_anal.c:4422
[...]
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #5219 (comment), or mute the thread https://github.com/notifications/unsubscribe/AA3-ljDBg1RBYRaqI2uM1OXzgeKH6aiPks5qP7JQgaJpZM4I-9fB.

axt · 2016-06-27T12:06:39Z

I wrote it in my previous comment, but maybe I wasn't exact enough, so:

The first backtrace is with #5218

This is c580004afe8a286d633244ed9b2baf7dbc9c57d9 of https://github.com/alvarofe/radare2.

The second is just there to show that the problem was not introduced by alvarofe-s pull request, it existed before (I saved the second trace around a week ago, don't know the exact version of it).

alvarofe · 2016-06-27T21:19:16Z

Check again with my PR to see if the issue is fixed, is just a workaround, we should detect why the variable name or type is null though without the binary is hard to debug. I don't know if you could cook a test case for us if the binary can't be shared.

axt · 2016-06-28T11:52:49Z

@alvarofe The SEGFAULT disappeared after your patch.

I've modified it to print more information:

- eprintf ("Warning null var at %s-%d\n", __FILE__, __LINE__);
+ eprintf ("Warning null var in fcn.0x%"PFMT64x".%c.%s at %s-%d\n", fcn->addr, kind, word, __FILE__, __LINE__);

I get this, after running Ps on the project:

Warning null var in fcn.0x56d68c.a.1.-104 at var.c-470
Warning null var in fcn.0x70dd60.a.1.-484 at var.c-470

If I do pdf @0x56d68c, it also SEGFAULTs.

If I just load the binary, and do an af @0x56d68c and then a pdf @0x56d68c then it works fine.

If anyone has an idea, how to track this down, i could try it, but unfortunatelly I can't share the binary.

radare · 2016-06-28T12:01:51Z

cc @oddcoder

On 28 Jun 2016, at 13:52, Attila Axt notifications@github.com wrote:

@alvarofe https://github.com/alvarofe The SEGFAULT disappeared after your patch.

I've modified it to print more information:

eprintf ("Warning null var at %s-%d\n", FILE, LINE);

eprintf ("Warning null var in fcn.0x%"PFMT64x".%c.%s at %s-%d\n", fcn->addr, kind, word, FILE, LINE);
I get this, after running Ps on the project:

Warning null var in fcn.0x56d68c.a.1.-104 at var.c-470
Warning null var in fcn.0x70dd60.a.1.-484 at var.c-470
If I do pdf @0x56d68c, it also SEGFAULTs.

If I just load the binary, and do an af @0x56d68c and then a pdf @0x56d68c then it works fine.

If anyone has an idea, how to track this down, i could try it, but unfortunatelly I can't share the binary.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #5219 (comment), or mute the thread https://github.com/notifications/unsubscribe/AA3-luAAwlsTyjT5C2pQgWtygwBuYykbks5qQQsTgaJpZM4I-9fB.

oddcoder · 2016-06-28T12:06:56Z

well I didn't create r_anal_var_list
plus debugging with out a binary is almost impossible !
never did anything similar
If sharing the binary is not possible I hope that atleast you can share only the function that caused the issue!

oddcoder · 2016-06-28T12:08:54Z

I guess the issue is that when deleting vars some references are kept somwhere in r_anal_var_list

alvarofe · 2016-06-28T19:36:20Z

Where does it segfault when using pdf @addr ?

radare · 2016-06-28T19:38:20Z

use the blind power of coverity

On 28 Jun 2016, at 21:36, Álvaro Felipe Melchor notifications@github.com wrote:

Where does it segfault when using pdf @addr ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #5219 (comment), or mute the thread https://github.com/notifications/unsubscribe/AA3-luTKJ4fwm3yNO7v_m_z4Hx-Kvj2iks5qQXe2gaJpZM4I-9fB.

axt · 2016-06-29T12:14:00Z

@oddcoder I think I could share the function, but thats why I tried that doing analysis on the function itself doesn't reproduce the problem.

@alvarofe

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) ba
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007ffff426782e in __GI___strdup (s=0x0) at strdup.c:41
#2  0x00007ffff64a18d2 in r_anal_var_get (a=0x5555557dd9a0, addr=5691020, 
    kind=97 'a', scope=1, delta=-104) at var.c:287
#3  0x00007ffff6499114 in get_used_var (anal=0x5555557dd9a0, op=0x7fffffff9ab0)
    at op.c:73
#4  0x00007ffff64992a4 in r_anal_op (anal=0x5555557dd9a0, op=0x7fffffff9ab0, 
    addr=5691282, data=0x555580d3b846 "\211M\230\270\330\331V", len=582)
    at op.c:100
[...]

Found another interesting problem with this executable. If I do r2 <executable> and then quit, it SEGFAULTs too.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff45cd5c1 in r_list_purge (list=0x7ffff460a4a0 <hash_sizes>) at list.c:66
66              RListIter *next = it->n;
(gdb) ba
#0  0x00007ffff45cd5c1 in r_list_purge (list=0x7ffff460a4a0 <hash_sizes>) at list.c:66
#1  0x00007ffff45cd627 in r_list_free (list=0x7ffff460a4a0 <hash_sizes>) at list.c:77
#2  0x00007ffff4ca5e2e in r_flag_free (f=0x555555809c30) at flags.c:108
#3  0x00007ffff7acb864 in r_core_fini (c=0x55555575c5c0 <r>) at core.c:1451
#4  0x000055555555a1e0 in main (argc=2, argv=0x7fffffffdc68, envp=0x7fffffffdc80) at radare2.c:1000

R_API void r_list_purge (RList *list) {
    if (list) {
        RListIter *it = list->head;
        while (it) {
[*]         RListIter *next = it->n;
            r_list_delete (list, it);
            it = next;
        }
        list->head = list->tail = NULL;
    }
}

In the marked line, the variable it will contain the value of 0x2 instead of a pointer. It looks like some kind of memory corruption problem. This case is a bit easier to test (because it doesn't require 2 hours to run), and maybe is related to the other problem.

Unfortunatelly I can't share the binary, but will try to to find the cause of this second bug on weekend, maybe it will help with the first bug. Any advices welcome, where or how to look.

radare · 2016-06-29T14:39:17Z

this is important for the release

axt · 2016-06-29T16:27:06Z

This publicly available program produces the second bug (SEGFAULT when quit), maybe solving that can lead in the right direction according the first issue:
http://delphiforfun.org/Programs/Download/CountGridCells.zip

To reproduce:

r2 CountGridCells.exe 
[0x00460834]> quit
Segmentation fault (core dumped)

radare · 2016-06-29T16:49:58Z

reproduce, this is a regression introduced by @alvarofe but its a different segfalt to the first one, so there are 2 different issues here

axt · 2016-06-29T17:57:21Z

Yes, its two different ones. I hoped they are related and solving this could help solve the first one.

Should I open another issue for this second segfault?

alvarofe · 2016-06-29T22:05:28Z

Fixed here #5238

radare · 2016-07-05T18:00:06Z

can we close this?

alvarofe · 2016-07-05T19:23:00Z

I fixed one of the segfault the other i couldn't reproduce

radare · 2016-07-05T20:47:45Z

Closing it for now. Please @axt reopen in case it is reproducible

axt · 2016-07-06T06:14:53Z

Yes I think its plausible to close it. I can't share the binary. But even if I could share: aac on that binary (18Mb) tooks 2 hours (tried with the sk2 branch too, which is still 50 minutes, but produces different results).

What you could do is that in the message the workaround by @alvarofe prints out, you could add something like "this should not happen, please report it as an issue", or something, so maybe somone else will run into it, and share a testcase.

Maijin · 2016-07-06T08:43:57Z

@crowell ^

radare · 2016-07-06T14:41:31Z

the slow performance is because of the patch from @ret2libc, its a known issue, but it is for correctness. @crowell and @ret2libc are working on a PR that fixes this problem. but im not sure if this patch will be available before the release that its actually delayed

On 06 Jul 2016, at 08:14, Attila Axt notifications@github.com wrote:

Yes I think its plausible to close it. I can't share the binary. But even if I could share: aac on that binary (18Mb) tooks 2 hours (tried with the sk2 branch too, which is still 50 minutes, but produces different results).

What you could do is that in the message the workaround by @alvarofe https://github.com/alvarofe prints out, you could add something like "this should not happen, please report it as an issue", or something, so maybe somone else will run into it, and share a testcase.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub #5219 (comment), or mute the thread https://github.com/notifications/unsubscribe/AA3-lkaIzYETqjlAUUSJc0BFtULTDbiDks5qS0fggaJpZM4I-9fB.

Maijin assigned oddcoder Jun 27, 2016

radare added this to the 0.10.4 milestone Jun 29, 2016

radare closed this as completed Jul 5, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Segfault when saving project after 'aac' #5219

Segfault when saving project after 'aac' #5219

axt commented Jun 27, 2016

radare commented Jun 27, 2016

axt commented Jun 27, 2016

radare commented Jun 27, 2016

axt commented Jun 27, 2016

alvarofe commented Jun 27, 2016

axt commented Jun 28, 2016

radare commented Jun 28, 2016

oddcoder commented Jun 28, 2016

oddcoder commented Jun 28, 2016

alvarofe commented Jun 28, 2016

radare commented Jun 28, 2016

axt commented Jun 29, 2016 •

edited

Loading

radare commented Jun 29, 2016

axt commented Jun 29, 2016

radare commented Jun 29, 2016

axt commented Jun 29, 2016 •

edited

Loading

alvarofe commented Jun 29, 2016

radare commented Jul 5, 2016

alvarofe commented Jul 5, 2016

radare commented Jul 5, 2016

axt commented Jul 6, 2016

Maijin commented Jul 6, 2016

radare commented Jul 6, 2016

Segfault when saving project after 'aac' #5219

Segfault when saving project after 'aac' #5219

Comments

axt commented Jun 27, 2016

radare commented Jun 27, 2016

axt commented Jun 27, 2016

radare commented Jun 27, 2016

axt commented Jun 27, 2016

alvarofe commented Jun 27, 2016

axt commented Jun 28, 2016

radare commented Jun 28, 2016

oddcoder commented Jun 28, 2016

oddcoder commented Jun 28, 2016

alvarofe commented Jun 28, 2016

radare commented Jun 28, 2016

axt commented Jun 29, 2016 • edited Loading

radare commented Jun 29, 2016

axt commented Jun 29, 2016

radare commented Jun 29, 2016

axt commented Jun 29, 2016 • edited Loading

alvarofe commented Jun 29, 2016

radare commented Jul 5, 2016

alvarofe commented Jul 5, 2016

radare commented Jul 5, 2016

axt commented Jul 6, 2016

Maijin commented Jul 6, 2016

radare commented Jul 6, 2016

axt commented Jun 29, 2016 •

edited

Loading

axt commented Jun 29, 2016 •

edited

Loading