Radare2: Segfault/memory exhaustion when analyzing ARM32 binary
Work environment
| Questions | Answers
|------------------------------------------------------|--------------------
| OS/arch/bits (mandatory) | Ubuntu x64
| File format of the file you reverse (mandatory) | ELF
| Architecture/bits of the file (mandatory) | ARM 32bits
| r2 -v full output, not truncated (mandatory) | radare2 2.9.0-git 19204 @ linux-x86-64 git.2.8.0-197-g10265a050. commit: 10265a050728fc530f5272b138aec17fb0e9fbf7 build: 2018-08-25__03:57:46
Expected behavior
Binary analyzed
Actual behavior
Crash
Steps to reproduce the behavior
- Please share the binary if it is shareable by drag and dropping it here in a zip archive (mandatory)
Cannot be shared sorry.
Additional Logs, screenshots, source-code, configuration dump, ...
[x] Analyze all flags starting with sym. and entry0 (aa)
[ ]
[Value from 0x00000000 to 0x00c56450
aav: 0x00000000-0x00c56450 in 0x0-0xc56450
aav: 0x00000000-0x00c56450 in 0xc58040-0xccb608
Value from 0x00c58040 to 0x00ccb608
aav: 0x00c58040-0x00ccb608 in 0x0-0xc56450
aav: 0x00c58040-0x00ccb608 in 0xc58040-0xccb608
[ WARNING : block size exceeding max block size at 0x0002817e
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00023d32
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x000135ca
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x000145e6
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00001bfa
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x0000243a
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x000033f6
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x000033e6
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x0000f93a
[+] Try changing it with e anal.bb.maxsize
==669==ERROR: AddressSanitizer failed to allocate 0x10000 (65536) bytes of memory at address 0x6250f6ca0 (error code: 12)
==669==Process memory map follows:
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x558dd6371000-0x558dd6385000 /home/syn/radare2/binr/radare2/radare2
0x558dd6584000-0x558dd6585000 /home/syn/radare2/binr/radare2/radare2
0x558dd6585000-0x558dd6589000 /home/syn/radare2/binr/radare2/radare2
0x558dd6589000-0x558dd65ea000
0x600000000000-0x602000000000
0x602000000000-0x602007260000
0x602007260000-0x602e00000000
0x602e00000000-0x602e00410000
0x602e00410000-0x603000000000
0x603000000000-0x60300ada0000
0x60300ada0000-0x603e00000000
0x603e00000000-0x603e000b0000
0x603e000b0000-0x604000000000
0x604000000000-0x604005dd0000
0x604005dd0000-0x604e00000000
0x604e00000000-0x604e000c0000
0x604e000c0000-0x606000000000
0x606000000000-0x606001760000
0x606001760000-0x606e00000000
0x606e00000000-0x606e00050000
0x606e00050000-0x607000000000
0x607000000000-0x6070000f0000
0x6070000f0000-0x607e00000000
0x607e00000000-0x607e00010000
0x607e00010000-0x608000000000
0x608000000000-0x6080031a0000
0x6080031a0000-0x608e00000000
0x608e00000000-0x608e00010000
0x608e00010000-0x60b000000000
0x60b000000000-0x60b001d80000
0x60b001d80000-0x60be00000000
0x60be00000000-0x60be000b0000
0x60be000b0000-0x60c000000000
0x60c000000000-0x60c000080000
0x60c000080000-0x60ce00000000
0x60ce00000000-0x60ce00010000
0x60ce00010000-0x60d000000000
0x60d000000000-0x60d000090000
0x60d000090000-0x60de00000000
0x60de00000000-0x60de00010000
0x60de00010000-0x60e000000000
0x60e000000000-0x60e0000a0000
0x60e0000a0000-0x60ee00000000
0x60ee00000000-0x60ee00010000
0x60ee00010000-0x60f000000000
0x60f000000000-0x60f0003a0000
0x60f0003a0000-0x60fe00000000
0x60fe00000000-0x60fe00010000
0x60fe00010000-0x610000000000
0x610000000000-0x610000140000
0x610000140000-0x610e00000000
0x610e00000000-0x610e00010000
0x610e00010000-0x611000000000
0x611000000000-0x611001010000
0x611001010000-0x611e00000000
0x611e00000000-0x611e00010000
0x611e00010000-0x612000000000
0x612000000000-0x612000320000
0x612000320000-0x612e00000000
0x612e00000000-0x612e00010000
0x612e00010000-0x613000000000
0x613000000000-0x613000380000
0x613000380000-0x613e00000000
0x613e00000000-0x613e00010000
0x613e00010000-0x614000000000
0x614000000000-0x6140003f0000
0x6140003f0000-0x614e00000000
0x614e00000000-0x614e00010000
0x614e00010000-0x615000000000
0x615000000000-0x6150004e0000
0x6150004e0000-0x615e00000000
0x615e00000000-0x615e00010000
0x615e00010000-0x616000000000
0x616000000000-0x616000ad0000
0x616000ad0000-0x616e00000000
0x616e00000000-0x616e00010000
0x616e00010000-0x617000000000
0x617000000000-0x617004080000
0x617004080000-0x617e00000000
0x617e00000000-0x617e00040000
0x617e00040000-0x618000000000
0x618000000000-0x618000c70000
0x618000c70000-0x618e00000000
0x618e00000000-0x618e00010000
0x618e00010000-0x619000000000
0x619000000000-0x619001ef0000
0x619001ef0000-0x619e00000000
0x619e00000000-0x619e00020000
0x619e00020000-0x61a000000000
0x61a000000000-0x61a0021a0000
0x61a0021a0000-0x61ae00000000
0x61ae00000000-0x61ae00020000
0x61ae00020000-0x61b000000000
0x61b000000000-0x61b0020d0000
0x61b0020d0000-0x61be00000000
0x61be00000000-0x61be00020000
0x61be00020000-0x61c000000000
0x61c000000000-0x61c002ef0000
0x61c002ef0000-0x61ce00000000
0x61ce00000000-0x61ce00010000
0x61ce00010000-0x61d000000000
0x61d000000000-0x61d004790000
0x61d004790000-0x61de00000000
0x61de00000000-0x61de00020000
0x61de00020000-0x61e000000000
0x61e000000000-0x61e001020000
0x61e001020000-0x61ee00000000
0x61ee00000000-0x61ee00010000
0x61ee00010000-0x61f000000000
0x61f000000000-0x61f000ca0000
0x61f000ca0000-0x61fe00000000
0x61fe00000000-0x61fe00010000
0x61fe00010000-0x620000000000
0x620000000000-0x620000ac0000
0x620000ac0000-0x620e00000000
0x620e00000000-0x620e00010000
0x620e00010000-0x621000000000
0x621000000000-0x621001ab0000
0x621001ab0000-0x621e00000000
0x621e00000000-0x621e00010000
0x621e00010000-0x622000000000
0x622000000000-0x622002920000
0x622002920000-0x622e00000000
0x622e00000000-0x622e00010000
0x622e00010000-0x623000000000
0x623000000000-0x6230030a0000
0x6230030a0000-0x623e00000000
0x623e00000000-0x623e00010000
0x623e00010000-0x624000000000
0x624000000000-0x624002900000
0x624002900000-0x624e00000000
0x624e00000000-0x624e00010000
0x624e00010000-0x625000000000
0x625000000000-0x6250f6ca0000
0x6250f6cb0000-0x625e00000000
0x625e00000000-0x625e00010000
0x625e00010000-0x626000000000
0x626000000000-0x6260000d0000
0x6260000d0000-0x626e00000000
0x626e00000000-0x626e00010000
0x626e00010000-0x629000000000
0x629000000000-0x6290035e0000
0x6290035e0000-0x629e00000000
0x629e00000000-0x629e00010000
0x629e00010000-0x62a000000000
0x62a000000000-0x62a000010000
0x62a000010000-0x62ae00000000
0x62ae00000000-0x62ae00010000
0x62ae00010000-0x62d000000000
0x62d000000000-0x62d000030000
0x62d000030000-0x62de00000000
0x62de00000000-0x62de00010000
0x62de00010000-0x630000000000
0x630000000000-0x630000050000
0x630000050000-0x630e00000000
0x630e00000000-0x630e00010000
0x630e00010000-0x631000000000
0x631000000000-0x631000040000
0x631000040000-0x631e00000000
0x631e00000000-0x631e00010000
0x631e00010000-0x634000000000
0x634000000000-0x634000020000
0x634000020000-0x634e00000000
0x634e00000000-0x634e00010000
0x634e00010000-0x640000000000
0x640000000000-0x640000003000
0x7f865cdc7000-0x7f867ee27000
0x7f867ee33000-0x7f86810b7000
0x7f86810b7000-0x7f8681d7f000 /xxxxxxxxxxxx/libTARGET.so
0x7f8681d7f000-0x7f8681d96000 /lib/x86_64-linux-gnu/libresolv-2.27.so
0x7f8681d96000-0x7f8681f96000 /lib/x86_64-linux-gnu/libresolv-2.27.so
0x7f8681f96000-0x7f8681f97000 /lib/x86_64-linux-gnu/libresolv-2.27.so
0x7f8681f97000-0x7f8681f98000 /lib/x86_64-linux-gnu/libresolv-2.27.so
0x7f8681f98000-0x7f8681f9a000
0x7f8681f9a000-0x7f8684df5000 /home/syn/.local/share/radare2/plugins/io_frida.so
0x7f8684df5000-0x7f8684ff5000 /home/syn/.local/share/radare2/plugins/io_frida.so
0x7f8684ff5000-0x7f868500c000 /home/syn/.local/share/radare2/plugins/io_frida.so
0x7f868500c000-0x7f86850e3000 /home/syn/.local/share/radare2/plugins/io_frida.so
0x7f86850e3000-0x7f86850f8000
0x7f8685100000-0x7f8686400000
0x7f8686403000-0x7f8686483000
0x7f8686490000-0x7f8686610000
0x7f8686610000-0x7f8686680000
0x7f8686687000-0x7f868669f000
0x7f868669f000-0x7f86866a2000 /home/syn/radare2/libr/asm/d/arm.sdb
0x7f86866a5000-0x7f86866b5000
0x7f86866b9000-0x7f86866bb000 /home/syn/radare2/libr/syscall/d/linux-arm-32.sdb
0x7f86866bb000-0x7f86866bd000 /home/syn/radare2/libr/syscall/d/linux-arm-32.sdb
0x7f86866bd000-0x7f8688bc8000
0x7f8688bc8000-0x7f8688bca000 /lib/x86_64-linux-gnu/libutil-2.27.so
0x7f8688bca000-0x7f8688dc9000 /lib/x86_64-linux-gnu/libutil-2.27.so
0x7f8688dc9000-0x7f8688dca000 /lib/x86_64-linux-gnu/libutil-2.27.so
0x7f8688dca000-0x7f8688dcb000 /lib/x86_64-linux-gnu/libutil-2.27.so
0x7f8688dcb000-0x7f8688de7000 /home/syn/radare2/libr/socket/libr_socket.so
0x7f8688de7000-0x7f8688fe6000 /home/syn/radare2/libr/socket/libr_socket.so
0x7f8688fe6000-0x7f8688fe7000 /home/syn/radare2/libr/socket/libr_socket.so
0x7f8688fe7000-0x7f8688fea000 /home/syn/radare2/libr/socket/libr_socket.so
0x7f8688fea000-0x7f8688ff7000 /home/syn/radare2/libr/lang/libr_lang.so
0x7f8688ff7000-0x7f86891f6000 /home/syn/radare2/libr/lang/libr_lang.so
0x7f86891f6000-0x7f86891f7000 /home/syn/radare2/libr/lang/libr_lang.so
0x7f86891f7000-0x7f86891fa000 /home/syn/radare2/libr/lang/libr_lang.so
0x7f86891fa000-0x7f8689211000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f8689211000-0x7f8689410000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f8689410000-0x7f8689411000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f8689411000-0x7f8689412000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f8689412000-0x7f86895af000 /lib/x86_64-linux-gnu/libm-2.27.so
0x7f86895af000-0x7f86897ae000 /lib/x86_64-linux-gnu/libm-2.27.so
0x7f86897ae000-0x7f86897af000 /lib/x86_64-linux-gnu/libm-2.27.so
0x7f86897af000-0x7f86897b0000 /lib/x86_64-linux-gnu/libm-2.27.so
0x7f86897b0000-0x7f86897b7000 /lib/x86_64-linux-gnu/librt-2.27.so
0x7f86897b7000-0x7f86899b6000 /lib/x86_64-linux-gnu/librt-2.27.so
0x7f86899b6000-0x7f86899b7000 /lib/x86_64-linux-gnu/librt-2.27.so
0x7f86899b7000-0x7f86899b8000 /lib/x86_64-linux-gnu/librt-2.27.so
0x7f86899b8000-0x7f86899bb000 /lib/x86_64-linux-gnu/libdl-2.27.so
0x7f86899bb000-0x7f8689bba000 /lib/x86_64-linux-gnu/libdl-2.27.so
0x7f8689bba000-0x7f8689bbb000 /lib/x86_64-linux-gnu/libdl-2.27.so
0x7f8689bbb000-0x7f8689bbc000 /lib/x86_64-linux-gnu/libdl-2.27.so
0x7f8689bbc000-0x7f8689da3000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7f8689da3000-0x7f8689fa3000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7f8689fa3000-0x7f8689fa7000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7f8689fa7000-0x7f8689fa9000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7f8689fa9000-0x7f8689fad000
0x7f8689fad000-0x7f8689fc7000 /lib/x86_64-linux-gnu/libpthread-2.27.so
0x7f8689fc7000-0x7f868a1c6000 /lib/x86_64-linux-gnu/libpthread-2.27.so
0x7f868a1c6000-0x7f868a1c7000 /lib/x86_64-linux-gnu/libpthread-2.27.so
0x7f868a1c7000-0x7f868a1c8000 /lib/x86_64-linux-gnu/libpthread-2.27.so
0x7f868a1c8000-0x7f868a1cc000
0x7f868a1cc000-0x7f868a3fc000 /home/syn/radare2/libr/util/libr_util.so
0x7f868a3fc000-0x7f868a5fb000 /home/syn/radare2/libr/util/libr_util.so
0x7f868a5fb000-0x7f868a5fd000 /home/syn/radare2/libr/util/libr_util.so
0x7f868a5fd000-0x7f868a669000 /home/syn/radare2/libr/util/libr_util.so
0x7f868a669000-0x7f868a674000
0x7f868a674000-0x7f868a6a0000 /home/syn/radare2/libr/crypto/libr_crypto.so
0x7f868a6a0000-0x7f868a89f000 /home/syn/radare2/libr/crypto/libr_crypto.so
0x7f868a89f000-0x7f868a8a0000 /home/syn/radare2/libr/crypto/libr_crypto.so
0x7f868a8a0000-0x7f868a8a4000 /home/syn/radare2/libr/crypto/libr_crypto.so
0x7f868a8a4000-0x7f868a8b6000
0x7f868a8b6000-0x7f868a8e6000 /home/syn/radare2/libr/egg/libr_egg.so
0x7f868a8e6000-0x7f868aae5000 /home/syn/radare2/libr/egg/libr_egg.so
0x7f868aae5000-0x7f868aae6000 /home/syn/radare2/libr/egg/libr_egg.so
0x7f868aae6000-0x7f868aaef000 /home/syn/radare2/libr/egg/libr_egg.so
0x7f868aaef000-0x7f868aafd000 /home/syn/radare2/libr/flag/libr_flag.so
0x7f868aafd000-0x7f868acfc000 /home/syn/radare2/libr/flag/libr_flag.so
0x7f868acfc000-0x7f868acfd000 /home/syn/radare2/libr/flag/libr_flag.so
0x7f868acfd000-0x7f868acfe000 /home/syn/radare2/libr/flag/libr_flag.so
0x7f868acfe000-0x7f868acff000
0x7f868acff000-0x7f868ad2c000 /home/syn/radare2/libr/magic/libr_magic.so
0x7f868ad2c000-0x7f868af2b000 /home/syn/radare2/libr/magic/libr_magic.so
0x7f868af2b000-0x7f868af2c000 /home/syn/radare2/libr/magic/libr_magic.so
0x7f868af2c000-0x7f868af30000 /home/syn/radare2/libr/magic/libr_magic.so
0x7f868af30000-0x7f868af47000 /home/syn/radare2/libr/hash/libr_hash.so
0x7f868af47000-0x7f868b147000 /home/syn/radare2/libr/hash/libr_hash.so
0x7f868b147000-0x7f868b148000 /home/syn/radare2/libr/hash/libr_hash.so
0x7f868b148000-0x7f868b14a000 /home/syn/radare2/libr/hash/libr_hash.so
0x7f868b14a000-0x7f868b153000 /home/syn/radare2/libr/syscall/libr_syscall.so
0x7f868b153000-0x7f868b352000 /home/syn/radare2/libr/syscall/libr_syscall.so
0x7f868b352000-0x7f868b353000 /home/syn/radare2/libr/syscall/libr_syscall.so
0x7f868b353000-0x7f868b357000 /home/syn/radare2/libr/syscall/libr_syscall.so
0x7f868b357000-0x7f868c1ef000 /home/syn/radare2/libr/asm/libr_asm.so
0x7f868c1ef000-0x7f868c3ef000 /home/syn/radare2/libr/asm/libr_asm.so
0x7f868c3ef000-0x7f868c4c9000 /home/syn/radare2/libr/asm/libr_asm.so
0x7f868c4c9000-0x7f868c89b000 /home/syn/radare2/libr/asm/libr_asm.so
0x7f868c89b000-0x7f868c9bc000
0x7f868c9bc000-0x7f868ca44000 /home/syn/radare2/libr/fs/libr_fs.so
0x7f868ca44000-0x7f868cc44000 /home/syn/radare2/libr/fs/libr_fs.so
0x7f868cc44000-0x7f868cc45000 /home/syn/radare2/libr/fs/libr_fs.so
0x7f868cc45000-0x7f868cc50000 /home/syn/radare2/libr/fs/libr_fs.so
0x7f868cc50000-0x7f868cc5c000
0x7f868cc5c000-0x7f868cd53000 /home/syn/radare2/libr/io/libr_io.so
0x7f868cd53000-0x7f868cf52000 /home/syn/radare2/libr/io/libr_io.so
0x7f868cf52000-0x7f868cf53000 /home/syn/radare2/libr/io/libr_io.so
0x7f868cf53000-0x7f868cf76000 /home/syn/radare2/libr/io/libr_io.so
0x7f868cf76000-0x7f868cf7f000
0x7f868cf7f000-0x7f868cf8a000 /home/syn/radare2/libr/bp/libr_bp.so
0x7f868cf8a000-0x7f868d189000 /home/syn/radare2/libr/bp/libr_bp.so
0x7f868d189000-0x7f868d18a000 /home/syn/radare2/libr/bp/libr_bp.so
0x7f868d18a000-0x7f868d18c000 /home/syn/radare2/libr/bp/libr_bp.so
0x7f868d18c000-0x7f868d1a1000 /home/syn/radare2/libr/reg/libr_reg.so
0x7f868d1a1000-0x7f868d3a0000 /home/syn/radare2/libr/reg/libr_reg.so
0x7f868d3a0000-0x7f868d3a1000 /home/syn/radare2/libr/reg/libr_reg.so
0x7f868d3a1000-0x7f868d3a3000 /home/syn/radare2/libr/reg/libr_reg.so
0x7f868d3a3000-0x7f868dfbe000 /home/syn/radare2/libr/anal/libr_anal.so
0x7f868dfbe000-0x7f868e1bd000 /home/syn/radare2/libr/anal/libr_anal.so
0x7f868e1bd000-0x7f868e21a000 /home/syn/radare2/libr/anal/libr_anal.so
0x7f868e21a000-0x7f868e4b7000 /home/syn/radare2/libr/anal/libr_anal.so
0x7f868e4b7000-0x7f868e5bd000
0x7f868e5bd000-0x7f868e630000 /home/syn/radare2/libr/debug/libr_debug.so
0x7f868e630000-0x7f868e82f000 /home/syn/radare2/libr/debug/libr_debug.so
0x7f868e82f000-0x7f868e830000 /home/syn/radare2/libr/debug/libr_debug.so
0x7f868e830000-0x7f868e83d000 /home/syn/radare2/libr/debug/libr_debug.so
0x7f868e83d000-0x7f868e83e000
0x7f868e83e000-0x7f868ebd2000 /home/syn/radare2/libr/bin/libr_bin.so
0x7f868ebd2000-0x7f868edd2000 /home/syn/radare2/libr/bin/libr_bin.so
0x7f868edd2000-0x7f868edd4000 /home/syn/radare2/libr/bin/libr_bin.so
0x7f868edd4000-0x7f868ee3f000 /home/syn/radare2/libr/bin/libr_bin.so
0x7f868ee3f000-0x7f868ee40000
0x7f868ee40000-0x7f868ee4b000 /home/syn/radare2/libr/config/libr_config.so
0x7f868ee4b000-0x7f868f04a000 /home/syn/radare2/libr/config/libr_config.so
0x7f868f04a000-0x7f868f04b000 /home/syn/radare2/libr/config/libr_config.so
0x7f868f04b000-0x7f868f04c000 /home/syn/radare2/libr/config/libr_config.so
0x7f868f04c000-0x7f868f099000 /home/syn/radare2/libr/cons/libr_cons.so
0x7f868f099000-0x7f868f298000 /home/syn/radare2/libr/cons/libr_cons.so
0x7f868f298000-0x7f868f299000 /home/syn/radare2/libr/cons/libr_cons.so
0x7f868f299000-0x7f868f2a2000 /home/syn/radare2/libr/cons/libr_cons.so
0x7f868f2a2000-0x7f868f2a5000
0x7f868f2a5000-0x7f868f2b1000 /home/syn/radare2/libr/search/libr_search.so
0x7f868f2b1000-0x7f868f4b0000 /home/syn/radare2/libr/search/libr_search.so
0x7f868f4b0000-0x7f868f4b1000 /home/syn/radare2/libr/search/libr_search.so
0x7f868f4b1000-0x7f868f4b2000 /home/syn/radare2/libr/search/libr_search.so
0x7f868f4b2000-0x7f868f59e000 /home/syn/radare2/libr/parse/libr_parse.so
0x7f868f59e000-0x7f868f79d000 /home/syn/radare2/libr/parse/libr_parse.so
0x7f868f79d000-0x7f868f79e000 /home/syn/radare2/libr/parse/libr_parse.so
0x7f868f79e000-0x7f868f7cf000 /home/syn/radare2/libr/parse/libr_parse.so
0x7f868f7cf000-0x7f868f7f1000
0x7f868f7f1000-0x7f868fcf6000 /home/syn/radare2/libr/core/libr_core.so
0x7f868fcf6000-0x7f868fef6000 /home/syn/radare2/libr/core/libr_core.so
0x7f868fef6000-0x7f868fef7000 /home/syn/radare2/libr/core/libr_core.so
0x7f868fef7000-0x7f868ffd2000 /home/syn/radare2/libr/core/libr_core.so
0x7f868ffd2000-0x7f868ffd7000
0x7f868ffd7000-0x7f8690127000 /usr/lib/x86_64-linux-gnu/libasan.so.4.0.0
0x7f8690127000-0x7f8690327000 /usr/lib/x86_64-linux-gnu/libasan.so.4.0.0
0x7f8690327000-0x7f869032a000 /usr/lib/x86_64-linux-gnu/libasan.so.4.0.0
0x7f869032a000-0x7f869032d000 /usr/lib/x86_64-linux-gnu/libasan.so.4.0.0
0x7f869032d000-0x7f8690f92000
0x7f8690f92000-0x7f8690fb9000 /lib/x86_64-linux-gnu/ld-2.27.so
0x7f8690fb9000-0x7f869119f000
0x7f869119f000-0x7f86911b9000
0x7f86911b9000-0x7f86911ba000 /lib/x86_64-linux-gnu/ld-2.27.so
0x7f86911ba000-0x7f86911bb000 /lib/x86_64-linux-gnu/ld-2.27.so
0x7f86911bb000-0x7f86911bc000
0x7ffc453be000-0x7ffc453e6000 [stack]
0x7ffc453e6000-0x7ffc453e7000
0x7ffc453f2000-0x7ffc453f5000 [vvar]
0x7ffc453f5000-0x7ffc453f7000 [vdso]
0xffffffffff600000-0xffffffffff601000 [vsyscall]
==669==End of process memory map.
==669==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_common.cc:118 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
ERROR: Failed to mmap
real 28m22.387s
user 26m15.895s
sys 1m12.430s
enovella
All 38 comments
[131972.508088] r2[6137]: segfault at 1a40 ip 00007f192b766747 sp 00007ffddf9ff0c0 error 4 in libr_util.so[7f192b6d1000+e0000]
[133584.275591] r2[6178]: segfault at 1320 ip 00007f79a972c747 sp 00007ffdec32f630 error 4 in libr_util.so (deleted)[7f79a9697000+e0000]
And where is the binary ?
Maijin
on 25 Aug 2018
Wheres the backtrace
On 25 Aug 2018, at 11:00, Maijin notifications@github.com wrote:
And where is the binary ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 25 Aug 2018
Hi,
@Maijin : I already mentioned that the binary cannot be shared. Sorry
@radare: This is what ASAN gave me. Even ASAN didn't give me a decent backtrace due to an mmap issue.
Cheers
enovella
on 25 Aug 2018
Trying similar binary with different laptop and r2 crashed my machine for 3 times in a row. It arrives to take up to 12GB RAM.
enovella
on 25 Aug 2018
so its a memory exhaustion problem?
try without asan with use gdb/lldb instead to get the backtrace
On 25 Aug 2018, at 16:54, Eduardo Novella notifications@github.com wrote:
Trying similar binary with different laptop and r2 crashed my machine for 3 times in a row. It arrives to take up to 12GB RAM.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/11229#issuecomment-415974619, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lsurQLoS_JqUOQDshGMfC-O7iJriks5uUWUbgaJpZM4WMPid.
radare
on 25 Aug 2018
Yeah @radare, it's a memory exhaustion issue and neither ASAN nor GDB are providing a backtrace.
This is the log of GDB when it jumped from 4GB to 11GB (probably during aar) and I broke the execution with ctrl+z.
$ gdb -q --args r2 -A libtarget.so
GEF for linux ready, type `gef' to start, `gef config' to configure
70 commands loaded for GDB 8.1.0.20180409-git using Python engine 3.6
Reading symbols from r2...done.
gef➤ r
Starting program: /usr/bin/r2 -A libtarget.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[x] Analyze all flags starting with sym. and entry0 (aa)
[ ]
[Value from 0x00000000 to 0x00d14920
aav: 0x00000000-0x00d14920 in 0x0-0xd14920
aav: 0x00000000-0x00d14920 in 0xd15fd0-0xd784d0
Value from 0x00d15fd0 to 0x00d784d0
aav: 0x00d15fd0-0x00d784d0 in 0x0-0xd14920
aav: 0x00d15fd0-0x00d784d0 in 0xd15fd0-0xd784d0
[ WARNING : block size exceeding max block size at 0x006b8ffc
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x009b5b0c
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x0026bffc
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00503c38
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x0055eff8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006105ec
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x009b595c
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006aaa64
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00c8bf80
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006c16d8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006c4ca8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006b15ac
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00cfe11c
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x0069e9c8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00cf8084
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00015214
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006c8954
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00cfba60
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00b52bd4
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00b4bcb0
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00456cd8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x00cc53c8
[+] Try changing it with e anal.bb.maxsize
WARNING : block size exceeding max block size at 0x006ca490
[+] Try changing it with e anal.bb.maxsize
[x] Analyze function calls (aac)
[ ] Analyze len bytes of instructions for references (aar)
^C
Program received signal SIGINT, Interrupt.
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ registers ]────
$rax : 0x5556425773c0 → 0x00005556425773e0 → 0x0000616337353834 ("4857ca"?)
$rbx : 0x0
$rcx : 0x55569bcb5e90 → 0x0000343834383834 ("488484"?)
$rdx : 0x38
$rsp : 0x7fffffffcf90 → 0x0000000000000000
$rbp : 0x7fffffffcfd0 → 0x00007fffffffd020 → 0x00007fffffffd070 → 0x00007fffffffd0a0 → 0x00007fffffffd120 → 0x00007fffffffd360 → 0x00007fffffffd3e0 → 0x00007fffffffd490
$rsi : 0x55569bcb5e90 → 0x0000343834383834 ("488484"?)
$rdi : 0x7ffff405b8c0 → 0x3900636432343934 ("4942dc"?)
$rip : 0x7ffff3df8db3 → <ht_find_kv+274> mov QWORD PTR [rbp-0x8], rax
$r8 : 0x0
$r9 : 0x0
$r10 : 0x0
$r11 : 0x7ffff6530903 → 0x2063257861007b00
$r12 : 0x555555557300 → <_start+0> xor ebp, ebp
$r13 : 0x7fffffffde20 → 0x0000000000000003
$r14 : 0x0
$r15 : 0x0
$eflags: [zero carry PARITY adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x0033 $es: 0x0000 $fs: 0x0000 $ds: 0x0000 $ss: 0x002b $gs: 0x0000
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ stack ]────
0x00007fffffffcf90│+0x00: 0x0000000000000000 ← $rsp
0x00007fffffffcf98│+0x08: 0x00007fffffffd057 → 0x005556bd96d6b000
0x00007fffffffcfa0│+0x10: 0x00007ffff405b8c0 → 0x3900636432343934 ("4942dc"?)
0x00007fffffffcfa8│+0x18: 0x000055555581da10 → 0x000af94c00000400
0x00007fffffffcfb0│+0x20: 0x0000000600ffcff0
0x00007fffffffcfb8│+0x28: 0x00000289d66da689
0x00007fffffffcfc0│+0x30: 0x0000555642577400 → 0x00005556425773c0 → 0x00005556425773e0 → 0x0000616337353834 ("4857ca"?)
0x00007fffffffcfc8│+0x38: 0x000055569bcb6010 → 0x000055569bcb5e90 → 0x0000343834383834 ("488484"?)
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ code:i386:x86-64 ]────
0x7ffff3df8da8 <ht_find_kv+263> lock add BYTE PTR [rdx+rdx*1+0x48], dh
0x7ffff3df8dad <ht_find_kv+268> mov eax, DWORD PTR [rbp-0x10]
0x7ffff3df8db0 <ht_find_kv+271> mov rax, QWORD PTR [rax]
→ 0x7ffff3df8db3 <ht_find_kv+274> mov QWORD PTR [rbp-0x8], rax
0x7ffff3df8db7 <ht_find_kv+278> cmp QWORD PTR [rbp-0x8], 0x0
0x7ffff3df8dbc <ht_find_kv+283> jne 0x7ffff3df8d4f <ht_find_kv+174>
0x7ffff3df8dbe <ht_find_kv+285> cmp QWORD PTR [rbp-0x38], 0x0
0x7ffff3df8dc3 <ht_find_kv+290> je 0x7ffff3df8dcc <ht_find_kv+299>
0x7ffff3df8dc5 <ht_find_kv+292> mov rax, QWORD PTR [rbp-0x38]
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ source:ht.c+256 ]────
251 }
252 ut32 key_len = ht->calcsizeK ((void *)key);
253 #endif
254 hash = ht->hashfn (key);
255 bucket = hash % ht->size;
// ht=0x00007fffffffcfa8 → [...] → 0x000af94c00000400, bucket=0x289, iter=0x00007fffffffcfc0 → [...] → 0x0000616337353834 ("4857ca"?), kv=0x00007fffffffcfc8 → [...] → 0x0000343834383834 ("488484"?)
→ 256 ls_foreach (ht->table[bucket], iter, kv) {
257 #if USE_KEYLEN
258 if (key_len != kv->key_len) {
259 continue;
260 }
261 #endif
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ threads ]────
[#0] Id 1, Name: "r2", stopped, reason: SIGINT
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ trace ]────
[#0] 0x7ffff3df8db3 → Name: ht_find_kv(ht=0x55555581da10, key=0x7ffff405b8c0 <Key.4290+1024> "4942dc", found=0x7fffffffd057)
[#1] 0x7ffff3df8e20 → Name: ht_find(ht=0x55555581da10, key=0x7ffff405b8c0 <Key.4290+1024> "4942dc", found=0x7fffffffd057)
[#2] 0x7ffff635d03f → Name: setxref(m=0x55555581da10, from=0x4942dc, to=0x4942b0, type=0x63)
[#3] 0x7ffff635d1da → Name: r_anal_xrefs_set(anal=0x5555557eb220, from=0x4942dc, to=0x4942b0, type=R_ANAL_REF_TYPE_CODE)
[#4] 0x7ffff7b1b189 → Name: found_xref(core=0x55555575f1c0 <r>, at=0x4942dc, xref_to=0x4942b0, type=R_ANAL_REF_TYPE_CODE, count=0x12e39f, rad=0x0, cfg_debug=0x0, cfg_anal_strings=0x0)
[#5] 0x7ffff7b1b856 → Name: r_core_anal_search_xrefs(core=0x55555575f1c0 <r>, from=0x0, to=0xd14920, rad=0x0)
[#6] 0x7ffff7a7c940 → Name: r_core_anal_refs(core=0x55555575f1c0 <r>, input=0x7ffff7b65cf8 "")
[#7] 0x7ffff7a7dfa7 → Name: cmd_anal_all(core=0x55555575f1c0 <r>, input=0x5555566efcd2 "a")
[#8] 0x7ffff7a7f338 → Name: cmd_anal(data=0x55555575f1c0 <r>, input=0x5555566efcd1 "aa")
[#9] 0x7ffff7b0dfee → Name: r_cmd_call(cmd=0x55555585f230, input=0x5555566efcd0 "aaa")
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0x00007ffff3df8db3 in ht_find_kv (ht=0x55555581da10, key=0x7ffff405b8c0 <Key.4290+1024> "4942dc", found=0x7fffffffd057) at ht.c:256
256 ls_foreach (ht->table[bucket], iter, kv) {
gef➤ Quit
what is the size of the bin?
wargio
on 25 Aug 2018
@wargio 14M
enovella
on 25 Aug 2018
maybe that's the issue.
wargio
on 25 Aug 2018
ida & bninja analyse the binary without collapsing the memory. Any workaround to analyse it with r2?
enovella
on 25 Aug 2018
There are 10000 ways to configure the analysis, aaa is a generic one, you probably should configure it to your needs and use the analysis commands and eval (search.in etc.) needed for your use-case.
Maijin
on 25 Aug 2018
10k ways I don't really know, but maybe some options could be.
[0x0002b000]> aa?
|Usage: aa[0*?] # see also 'af' and 'afna'
| aa alias for 'af@@ sym.*;af@entry0;afva'
| aa* analyze all flags starting with sym. (af @@ sym.*)
| aaa[?] autoname functions after aa (see afna)
| aab aab across bin.sections.rx
| aac [len] analyze function calls (af @@ `pi len~call[1]`)
| aac* [len] flag function calls without performing a complete analysis
| aad [len] analyze data references to code
| aae [len] ([addr]) analyze references with ESIL (optionally to address)
| aaE run aef on all functions (same as aef @@f)
| aaf analyze all functions (e anal.hasnext=1;afr @@c:isq)
| aai[j] show info of all analysis parameters
| aan autoname functions that either start with fcn.* or sym.func.*
| aap find and analyze function preludes
| aar[?] [len] analyze len bytes of instructions for references
| aas [len] analyze symbols (af @@= `isq~[0]`)
| aat [len] analyze all consecutive functions in section
| aaT [len] analyze code after trap-sleds
| aau [len] list mem areas (larger than len bytes) not covered by functions
| aav [sat] find values referencing a specific section or map
Experimenting with different analysis now, I will share results when they're done.
enovella
on 26 Aug 2018
use memgrind to help us find the memory leaks or bottlenecks.
On 25 Aug 2018, at 20:25, Eduardo Novella notifications@github.com wrote:
ida & bninja analyse the binary without collapsing the memory. Any workaround to analyse with r2?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/11229#issuecomment-415987804, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lgDSxdRxffsssgeHwmEyhhCRlAZkks5uUZaugaJpZM4WMPid.
radare
on 26 Aug 2018
there are many more anal. vars to tweak the behaviour of all the a* subcommands. so its more than 10k.
btw, i would focus on profiling r2 and fix the mem issue, maskray fixed a bunch of them tonight, so maybe your problem is gone
On 26 Aug 2018, at 02:35, Eduardo Novella notifications@github.com wrote:
10k ways I don't really know, but maybe some options could be. Keep calm @Maijin https://github.com/Maijin :)
[0x0002b000]> aa?
|Usage: aa[0?] # see also 'af' and 'afna'
| aa alias for 'af@@ sym.;af@entry0;afva'
| aa* analyze all flags starting with sym. (af @@ sym.)
| aaa[?] autoname functions after aa (see afna)
| aab aab across bin.sections.rx
| aac [len] analyze function calls (af @@pi len~call[1])
| aac [len] flag function calls without performing a complete analysis
| aad [len] analyze data references to code
| aae [len] ([addr]) analyze references with ESIL (optionally to address)
| aaE run aef on all functions (same as aef @@f)
| aaf analyze all functions (e anal.hasnext=1;afr @@c:isq)
| aai[j] show info of all analysis parameters
| aan autoname functions that either start with fcn.* or sym.func.*
| aap find and analyze function preludes
| aar[?] [len] analyze len bytes of instructions for references
| aas [len] analyze symbols (af @@=isq~[0])
| aat [len] analyze all consecutive functions in section
| aaT [len] analyze code after trap-sleds
| aau [len] list mem areas (larger than len bytes) not covered by functions
| aav [sat] find values referencing a specific section or map
Experimenting with different analysis now, I will share results when they're done.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/11229#issuecomment-416005438, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lgJAQXcS_Oz70ET9x3eNqzVts1_kks5uUe08gaJpZM4WMPid.
radare
on 26 Aug 2018
As discussed with you over Telegram, there's a problem with Valgrind and Ubuntu that kills the execution when memory is exhausted.
This is what I could get when broke the execution of valgrind --leak-check=yes r2 -A lib.so
==6310== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x625E8A9: r_anal_hint_from_string (hint.c:185)
==6310== by 0x625EC0B: r_anal_hint_get (hint.c:239)
==6310== by 0x4F7F3A4: core_anal_fcn (canal.c:589)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F88DE9: r_core_anal_all (canal.c:3220)
==6310== by 0x4EEAE23: cmd_anal_all (cmd_anal.c:6987)
==6310== by 0x4EEC440: cmd_anal (cmd_anal.c:7405)
==6310== by 0x4F7B1A6: r_cmd_call (cmd_api.c:237)
==6310== by 0x4F30B35: r_core_cmd_subst_i (cmd.c:2901)
==6310== by 0x4F2D696: r_core_cmd_subst (cmd.c:1930)
==6310== by 0x4F33290: r_core_cmd (cmd.c:3605)
==6310==
==6310== 161 bytes in 1 blocks are definitely lost in loss record 19,573 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x6136034: analop_esil (anal_arm_cs.c:1559)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 161 bytes in 1 blocks are definitely lost in loss record 19,574 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x6136034: analop_esil (anal_arm_cs.c:1559)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,598 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,599 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,600 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,601 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,602 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,603 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 167 bytes in 1 blocks are definitely lost in loss record 19,604 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x6255FF8: r_anal_fcn (fcn.c:1617)
==6310==
==6310== 170 bytes in 1 blocks are definitely lost in loss record 20,182 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x6255FF8: r_anal_fcn (fcn.c:1617)
==6310== by 0x4F7F5FA: core_anal_fcn (canal.c:626)
==6310==
==6310== 171 bytes in 1 blocks are definitely lost in loss record 20,190 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 171 bytes in 1 blocks are definitely lost in loss record 20,191 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 307 bytes in 1 blocks are definitely lost in loss record 23,688 of 41,769
==6310== at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FD35: r_strbuf_append_n (strbuf.c:114)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 307 bytes in 1 blocks are definitely lost in loss record 23,689 of 41,769
==6310== at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FD35: r_strbuf_append_n (strbuf.c:114)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 330 bytes in 22 blocks are definitely lost in loss record 24,039 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C573D2: sdb_array_set (array.c:375)
==6310== by 0x625E1F5: setHint (hint.c:48)
==6310== by 0x625E5BD: r_anal_hint_set_bits (hint.c:115)
==6310== by 0x4F6BB26: bin_symbols_internal (cbin.c:1916)
==6310== by 0x4F6C815: bin_symbols (cbin.c:2119)
==6310== by 0x4F71B46: r_core_bin_info (cbin.c:3415)
==6310== by 0x4F653B4: r_core_bin_set_env (cbin.c:124)
==6310== by 0x4F36354: r_core_file_do_load_for_io_plugin (cfile.c:390)
==6310== by 0x4F36B52: r_core_bin_load (cfile.c:543)
==6310== by 0x10E66B: main (radare2.c:1086)
==6310==
==6310== 334 bytes in 2 blocks are definitely lost in loss record 24,053 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 341 bytes in 2 blocks are definitely lost in loss record 24,361 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310==
==6310== 341 bytes in 2 blocks are definitely lost in loss record 24,362 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310== by 0x6255FF8: r_anal_fcn (fcn.c:1617)
==6310==
==6310== 392 (224 direct, 168 indirect) bytes in 7 blocks are definitely lost in loss record 25,198 of 41,769
==6310== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C07363: r_list_new (list.c:155)
==6310== by 0x6250E21: r_anal_fcn_list_new (fcn.c:306)
==6310== by 0x4F7FB53: core_anal_fcn (canal.c:723)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310== by 0x4F7FD6B: core_anal_fcn (canal.c:760)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310== by 0x4F7FD6B: core_anal_fcn (canal.c:760)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310==
==6310== 501 bytes in 3 blocks are definitely lost in loss record 26,433 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310==
==6310== 501 bytes in 3 blocks are definitely lost in loss record 26,434 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310==
==6310== 501 bytes in 3 blocks are definitely lost in loss record 26,435 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFA9: opex (anal_arm_cs.c:230)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 511 bytes in 3 blocks are definitely lost in loss record 26,616 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 567 (32 direct, 535 indirect) bytes in 1 blocks are definitely lost in loss record 27,151 of 41,769
==6310== at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x4E9C900: r_core_autocomplete_add (core.c:3173)
==6310== by 0xB6D3917: r_cmd_pdd_init (core_pdd.c:237)
==6310== by 0x4FB49E6: r_core_plugin_add (plugin.c:33)
==6310== by 0x4F52BBD: __lib_core_cb (libs.c:32)
==6310== by 0x8C30583: r_lib_run_handler (lib.c:171)
==6310== by 0x8C30CAB: r_lib_open_ptr (lib.c:320)
==6310== by 0x8C30AC5: r_lib_open (lib.c:280)
==6310== by 0x8C30E89: r_lib_opendir (lib.c:400)
==6310== by 0x4F53329: r_core_loadlibs (libs.c:91)
==6310== by 0x10D413: main (radare2.c:812)
==6310==
==6310== 616 (352 direct, 264 indirect) bytes in 11 blocks are definitely lost in loss record 27,640 of 41,769
==6310== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C07363: r_list_new (list.c:155)
==6310== by 0x6250E21: r_anal_fcn_list_new (fcn.c:306)
==6310== by 0x4F7FB53: core_anal_fcn (canal.c:723)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310== by 0x4F7FD6B: core_anal_fcn (canal.c:760)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310== by 0x4F7FD6B: core_anal_fcn (canal.c:760)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4EE3CEB: _anal_calls (cmd_anal.c:5051)
==6310==
==6310== 851 bytes in 5 blocks are definitely lost in loss record 29,246 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x625456F: fcn_recurse (fcn.c:1261)
==6310==
==6310== 851 bytes in 5 blocks are definitely lost in loss record 29,247 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 1,196 bytes in 7 blocks are definitely lost in loss record 30,648 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 1,400 (800 direct, 600 indirect) bytes in 25 blocks are definitely lost in loss record 31,282 of 41,769
==6310== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C07363: r_list_new (list.c:155)
==6310== by 0x6250E21: r_anal_fcn_list_new (fcn.c:306)
==6310== by 0x4F7FB53: core_anal_fcn (canal.c:723)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4F7F128: r_anal_analyze_fcn_refs (canal.c:534)
==6310== by 0x4F7FD6B: core_anal_fcn (canal.c:760)
==6310== by 0x4F82F6F: r_core_anal_fcn (canal.c:1551)
==6310== by 0x4EE3CEB: _anal_calls (cmd_anal.c:5051)
==6310== by 0x4EE400E: cmd_anal_calls (cmd_anal.c:5122)
==6310== by 0x4EEB034: cmd_anal_all (cmd_anal.c:7022)
==6310== by 0x4EEC440: cmd_anal (cmd_anal.c:7405)
==6310==
==6310== 2,217 bytes in 13 blocks are definitely lost in loss record 32,843 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310==
==6310== 2,387 bytes in 14 blocks are definitely lost in loss record 33,097 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 3,071 bytes in 18 blocks are definitely lost in loss record 33,781 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C2FCCD: r_strbuf_append_n (strbuf.c:109)
==6310== by 0x8C2FC0F: r_strbuf_append (strbuf.c:94)
==6310== by 0x8C2FF61: r_strbuf_appendf (strbuf.c:149)
==6310== by 0x612FFE0: opex (anal_arm_cs.c:234)
==6310== by 0x613552C: analop_esil (anal_arm_cs.c:1448)
==6310== by 0x613E5A5: analop (anal_arm_cs.c:2946)
==6310== by 0x624E59D: r_anal_op (op.c:154)
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x6254996: fcn_recurse (fcn.c:1305)
==6310== by 0x62548EC: fcn_recurse (fcn.c:1304)
==6310==
==6310== 29,016 bytes in 279 blocks are definitely lost in loss record 38,709 of 41,769
==6310== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x625E8A9: r_anal_hint_from_string (hint.c:185)
==6310== by 0x625EC0B: r_anal_hint_get (hint.c:239)
==6310== by 0x4EE3B8A: _anal_calls (cmd_anal.c:5028)
==6310== by 0x4EE400E: cmd_anal_calls (cmd_anal.c:5122)
==6310== by 0x4EEB034: cmd_anal_all (cmd_anal.c:7022)
==6310== by 0x4EEC440: cmd_anal (cmd_anal.c:7405)
==6310== by 0x4F7B1A6: r_cmd_call (cmd_api.c:237)
==6310== by 0x4F30B35: r_core_cmd_subst_i (cmd.c:2901)
==6310== by 0x4F2D696: r_core_cmd_subst (cmd.c:1930)
==6310== by 0x4F33290: r_core_cmd (cmd.c:3605)
==6310== by 0x4F339E5: r_core_cmd0 (cmd.c:3769)
==6310==
==6310== 347,055 bytes in 23,137 blocks are definitely lost in loss record 41,023 of 41,769
==6310== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6310== by 0x8C573D2: sdb_array_set (array.c:375)
==6310== by 0x625E1F5: setHint (hint.c:48)
==6310== by 0x625E5BD: r_anal_hint_set_bits (hint.c:115)
==6310== by 0x4EEA3E5: _CbInRangeAav (cmd_anal.c:6805)
==6310== by 0x4E9C7C2: r_core_search_value_in_range (core.c:3150)
==6310== by 0x4EEA92C: cmd_anal_aav (cmd_anal.c:6899)
==6310== by 0x4EEAC16: cmd_anal_all (cmd_anal.c:6947)
==6310== by 0x4EEC440: cmd_anal (cmd_anal.c:7405)
==6310== by 0x4F7B1A6: r_cmd_call (cmd_api.c:237)
==6310== by 0x4F30B35: r_core_cmd_subst_i (cmd.c:2901)
==6310== by 0x4F2D696: r_core_cmd_subst (cmd.c:1930)
==6310==
==6310== LEAK SUMMARY:
==6310== definitely lost: 394,244 bytes in 23,581 blocks
==6310== indirectly lost: 1,567 bytes in 68 blocks
==6310== possibly lost: 0 bytes in 0 blocks
==6310== still reachable: 3,359,925,246 bytes in 9,262,522 blocks
==6310== suppressed: 0 bytes in 0 blocks
==6310== Reachable blocks (those to which a pointer was found) are not shown.
==6310== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6310==
==6310== For counts of detected and suppressed errors, rerun with: -v
==6310== ERROR SUMMARY: 37 errors from 37 contexts (suppressed: 0 from 0)
Terminated
i dont think those small leaks are causing the problem, but will be good to fix them anyways.
usually debian kernel kills apps that do big allocations in small time, but enotime to testing now
On 27 Aug 2018, at 12:42, Eduardo Novella notifications@github.com wrote:
==6310== by 0x6252DB5: fcn_recurse (fcn.c:982)
radare
on 31 Aug 2018
ok, just upgraded r2 and the issue remains with default analysis (-A in the shell). Let's discuss it on the near future.
enovella
on 2 Sep 2018
From this message the memory comsumption is around 100MB per second
[ ] Analyze len bytes of instructions for references (aar)
I have fixed the memleak issues in aar, but the main problem is that xrefs take so much memory because of the hashtable.
radare
on 22 Sep 2018
We can try to switch to bloom filter for them, will require a lot less
space @ret2libc @MaskRay
https://stackoverflow.com/questions/4282375/what-is-the-advantage-to-using-bloom-filters
On Sat, Sep 22, 2018, 6:37 AM radare notifications@github.com wrote:
I have fixed the memleak issues in aar, but the main problem is that xrefs
take so much memory because of the hashtable.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/radare/radare2/issues/11229#issuecomment-423688947,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMZ_USaahWpqUKiovSRqCeDYhuPe6l_ks5udWougaJpZM4WMPid
.
XVilka
on 22 Sep 2018
How many xrefs are there? Did you print the number? At least we can have an idea.
ret2libc
on 22 Sep 2018
Millions of them. Its a 32MB binary. But you can do rhe test with smaller samples and notice that aar makes the proces grow by 50-100MB/s just because of the xrefs storage
On 22 Sep 2018, at 09:23, Riccardo Schirone notifications@github.com wrote:
How many xrefs are there? Did you print the number? At least we can have an idea.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 22 Sep 2018
I'd like to see the binary. I wouldn't start switching to bloom filters or other things before confirming it's really xrefs problem. Even if it's a 32MB binary and we assume there is an xrefs for each byte of the binary (which I doubt) and considering a RAnalRef is 20 byte (maybe even less)... 33554432 * 20 byte * 2 (because there are 2 hashtables) == 1280 MB. Let's say it's even double that because there are other data structures to be considered for each element in the hashtable... it's still "only" ~2 GB of data and I'm not sure the program should crash with such memory consumption (unless we are on 32bit systems).
ret2libc
on 22 Sep 2018
I was testing with only aar. So yes. Its xrefs specific issue. And you may reproduce this with any other big binary tor any other arch
On 22 Sep 2018, at 12:21, Riccardo Schirone notifications@github.com wrote:
I'd like to see the binary. I wouldn't start switching to bloom filters or other things before confirming it's really xrefs problem. Even if it's a 32MB binary and we assume there is an xrefs for each byte of the binary (which I doubt) and considering a RAnalRef is 20 byte (maybe even less)... 33554432 * 20 byte * 2 (because there are 2 hashtables) == 1280 MB. Let's say it's even double that because there are other data structures to be considered for each element in the hashtable... it's still "only" ~2 GB of data and I'm not sure the program should crash with such memory consumption (unless we are on 32bit systems).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 22 Sep 2018
The memory required is way more than 10GB. I personally dont have the patience to wait that much to know the final value. And this can be tested with an r2 script
On 22 Sep 2018, at 12:21, Riccardo Schirone notifications@github.com wrote:
I'd like to see the binary. I wouldn't start switching to bloom filters or other things before confirming it's really xrefs problem. Even if it's a 32MB binary and we assume there is an xrefs for each byte of the binary (which I doubt) and considering a RAnalRef is 20 byte (maybe even less)... 33554432 * 20 byte * 2 (because there are 2 hashtables) == 1280 MB. Let's say it's even double that because there are other data structures to be considered for each element in the hashtable... it's still "only" ~2 GB of data and I'm not sure the program should crash with such memory consumption (unless we are on 32bit systems).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 22 Sep 2018
So you get a crash on every big binary when you do aar?
ret2libc
on 22 Sep 2018
I dont get a crash because i dont use debian
On 22 Sep 2018, at 13:34, Riccardo Schirone notifications@github.com wrote:
So you get a crash on every big binary when you do aar?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 22 Sep 2018
Tracing a crash on r2frida led me to analyze frida agent. Also the memory consumption collapsed my laptop with 12GB RAM.
adare2 3.0.0-git 19655 @ linux-x86-64 git.2.9.0-194-ga36534b9f
commit: a36534b9f380905bd6d561bea4c552b3937ed117 build: 2018-09-24__12:39:16
Can anyone reproduce?
enovella
on 24 Sep 2018
Thanks @enovella ! After running it with massif this is what I got at the peak snapshot.
--------------------------------------------------------------------------------
n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
52 99,248,529,000 10,916,538,656 10,661,118,323 255,420,333 0
97.66% (10,661,118,323B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->92.80% (10,130,874,368B) 0x4EC0521: internal_ht_new (ht.c:49)
| ->92.80% (10,130,874,368B) 0x4EC0745: ht_new (ht.c:109)
| ->92.80% (10,130,571,264B) 0x783FBA2: setxref (xrefs.c:113)
| | ->70.42% (7,687,888,896B) 0x783FCFE: r_anal_xrefs_set (xrefs.c:137)
| | | ->70.42% (7,687,888,896B) 0x51766A7: found_xref (canal.c:3126)
| | | ->30.72% (3,353,452,544B) 0x5176BB0: r_core_anal_search_xrefs (canal.c:3226)
| | | | ->30.72% (3,353,452,544B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | | ->30.72% (3,353,452,544B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | | ->30.72% (3,353,452,544B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
| | | | ->30.72% (3,353,452,544B) 0x5227E86: r_cmd_call (cmd_api.c:239)
| | | | ->30.72% (3,353,452,544B) 0x5222F6B: r_core_cmd_subst_i (cmd.c:2960)
| | | | ->30.72% (3,353,452,544B) 0x521FE31: r_core_cmd_subst (cmd.c:1966)
| | | | ->30.72% (3,353,452,544B) 0x5225454: r_core_cmd (cmd.c:3679)
| | | | ->30.72% (3,353,452,544B) 0x404158: run_commands (radare2.c:366)
| | | | ->30.72% (3,353,452,544B) 0x40739F: main (radare2.c:1386)
| | | |
| | | ->25.14% (2,744,819,712B) 0x5176CB1: r_core_anal_search_xrefs (canal.c:3231)
| | | | ->25.14% (2,744,819,712B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | | ->25.14% (2,744,819,712B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | | ->25.14% (2,744,819,712B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
| | | | ->25.14% (2,744,819,712B) 0x5227E86: r_cmd_call (cmd_api.c:239)
| | | | ->25.14% (2,744,819,712B) 0x5222F6B: r_core_cmd_subst_i (cmd.c:2960)
| | | | ->25.14% (2,744,819,712B) 0x521FE31: r_core_cmd_subst (cmd.c:1966)
| | | | ->25.14% (2,744,819,712B) 0x5225454: r_core_cmd (cmd.c:3679)
| | | | ->25.14% (2,744,819,712B) 0x404158: run_commands (radare2.c:366)
| | | | ->25.14% (2,744,819,712B) 0x40739F: main (radare2.c:1386)
| | | |
| | | ->14.56% (1,589,616,640B) 0x5176CF5: r_core_anal_search_xrefs (canal.c:3235)
| | | ->14.56% (1,589,616,640B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | ->14.56% (1,589,616,640B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | ->14.56% (1,589,616,640B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
...
Now, why most of the heap is used for internal_ht_new? I think the reason is in how we store xrefs. We have one hashtable that uses as key the from address and as value another hashtable. Inside the "inner" hashtable, we use the to address as key and as value the RAnalRef object. What I think happens is that most of the references are from different from addresses, meaning that every new ref will create a new hashtable as well (which occupies a bit of memory...).
Now... why didn't we use just one hashtable with key (from,to)? The reason was that sometimes we do need to find all references from a given address or we need to find all references in a given function... I don't have a solution at the moment.
ret2libc
on 24 Sep 2018
Ok so... I'm already working on improving the ht used when computing xrefs. Main thing is, for some reasons, current ht have growing disabled so by default the size is 1024, which is quite a lot of memory. I will come back to this issue after improving ht.
ret2libc
on 24 Sep 2018
Try 1000000ax 1 2 or 1000000pd 0 and u’ll experiment more memleaks
On 24 Sep 2018, at 09:18, Riccardo Schirone notifications@github.com wrote:
Thanks @enovella ! After running it with massif this is what I got at the peak snapshot.
n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
52 99,248,529,000 10,916,538,656 10,661,118,323 255,420,333 0
97.66% (10,661,118,323B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->92.80% (10,130,874,368B) 0x4EC0521: internal_ht_new (ht.c:49)
| ->92.80% (10,130,874,368B) 0x4EC0745: ht_new (ht.c:109)
| ->92.80% (10,130,571,264B) 0x783FBA2: setxref (xrefs.c:113)
| | ->70.42% (7,687,888,896B) 0x783FCFE: r_anal_xrefs_set (xrefs.c:137)
| | | ->70.42% (7,687,888,896B) 0x51766A7: found_xref (canal.c:3126)
| | | ->30.72% (3,353,452,544B) 0x5176BB0: r_core_anal_search_xrefs (canal.c:3226)
| | | | ->30.72% (3,353,452,544B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | | ->30.72% (3,353,452,544B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | | ->30.72% (3,353,452,544B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
| | | | ->30.72% (3,353,452,544B) 0x5227E86: r_cmd_call (cmd_api.c:239)
| | | | ->30.72% (3,353,452,544B) 0x5222F6B: r_core_cmd_subst_i (cmd.c:2960)
| | | | ->30.72% (3,353,452,544B) 0x521FE31: r_core_cmd_subst (cmd.c:1966)
| | | | ->30.72% (3,353,452,544B) 0x5225454: r_core_cmd (cmd.c:3679)
| | | | ->30.72% (3,353,452,544B) 0x404158: run_commands (radare2.c:366)
| | | | ->30.72% (3,353,452,544B) 0x40739F: main (radare2.c:1386)
| | | |
| | | ->25.14% (2,744,819,712B) 0x5176CB1: r_core_anal_search_xrefs (canal.c:3231)
| | | | ->25.14% (2,744,819,712B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | | ->25.14% (2,744,819,712B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | | ->25.14% (2,744,819,712B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
| | | | ->25.14% (2,744,819,712B) 0x5227E86: r_cmd_call (cmd_api.c:239)
| | | | ->25.14% (2,744,819,712B) 0x5222F6B: r_core_cmd_subst_i (cmd.c:2960)
| | | | ->25.14% (2,744,819,712B) 0x521FE31: r_core_cmd_subst (cmd.c:1966)
| | | | ->25.14% (2,744,819,712B) 0x5225454: r_core_cmd (cmd.c:3679)
| | | | ->25.14% (2,744,819,712B) 0x404158: run_commands (radare2.c:366)
| | | | ->25.14% (2,744,819,712B) 0x40739F: main (radare2.c:1386)
| | | |
| | | ->14.56% (1,589,616,640B) 0x5176CF5: r_core_anal_search_xrefs (canal.c:3235)
| | | ->14.56% (1,589,616,640B) 0x51DEAFF: r_core_anal_refs (cmd_anal.c:6702)
| | | ->14.56% (1,589,616,640B) 0x51E08D8: cmd_anal_all (cmd_anal.c:7230)
| | | ->14.56% (1,589,616,640B) 0x51E1573: cmd_anal (cmd_anal.c:7490)
...
Now, why most of the heap is used for internal_ht_new? I think the reason is in how we store xrefs. We have one hashtable that uses as key the from address and as value another hashtable. Inside the "inner" hashtable, we use the to address as key and as value the RAnalRef object. What I think happens is that most of the references are from different from addresses, meaning that every new ref will create a new hashtable as well (which occupies a bit of memory...).Now... why didn't we use just one hashtable with key (from,to)? The reason was that sometimes we do need to find all references from a given address or we need to find all references in a given function... I don't have a solution at the moment.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 24 Sep 2018
I moved this to "In progress" because we have PRs in radare/sdb (https://github.com/radare/sdb/pull/160 and others that will come after this) to improve the hash table used in r2. This PR already should reduce considerably the memory usage, since it won't allocate 1024 entries by default for each hashtable but only few.
ret2libc
on 27 Sep 2018
This should be fixed with https://github.com/radare/radare2/pull/11776 but it will probably land in 3.1.0 so that we have more time to test it.
ret2libc
on 11 Oct 2018
Ok actually... I just merged the PR. So please help us test it in these last days before release. It should fix your problem and allow you to analyze big binaries. Yes, it will still be slow in some operations, but aar at least shouldn't eat all your memory and it should be much faster now.
ret2libc
on 11 Oct 2018
Reopen if it doesn't work.
ret2libc
on 11 Oct 2018
Lovely @ret2libc! It works here. Great job.
Many thanks!
enovella
on 13 Oct 2018
The good fix would be to make xrefs not allocate over 9000000 hashtables for something that can be done with only 2. But yeah its an improvement in expense of slower insertions. There are several more improvements to be done to make lists and hashtables faster still
On 13 Oct 2018, at 11:16, Eduardo Novella notifications@github.com wrote:
Lovely @ret2libc! It works here. Great job.
Many thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
radare
on 13 Oct 2018
Related issues
eagleoflqj
·
7Comments
ret2libc
·
6Comments
unixfreaxjp
·
8Comments
MariasStory
·
6Comments
NotAFile
·
6Comments