Radare2: pdb segfaults on Linux

[EvanCarroll]

Using the same information about build and system here..

Download

wget http://msdl.microsoft.com/download/symbols/sqllang.pdb/40D5A1EFAD844ABFA5A689F2E49153E12/sqllang.pdb

Sum

md5sum /tmp/sqllang.pdb
3e1007a0bd83d5c1df6015f15fe1b714  /tmp/sqllang.pdb

Run with -P, or load with idp

rabin2 -P /tmp/sqllang.pdb 
Segmentation fault (core dumped)

[mscherer]

Here, it start to consume close to 5 or 6G of ram (out of 12). Does it crash due to out of memory on your side ?

[lowlyw]

busytown /tmp » lldb rabin2 -P ./sqllang.pdb                                                                                                                                                              139 ↵
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python
busytown /tmp » lldb -- rabin2 -P ./sqllang.pdb
(lldb) target create "rabin2"
Current executable set to 'rabin2' (x86_64).
(lldb) settings set -- target.run-args  "-P" "./sqllang.pdb"
(lldb) r
Process 28796 launched: '/usr/local/bin/rabin2' (x86_64)
Process 28796 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff5a7e2432 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen:
->  0x7fff5a7e2432 <+18>: pcmpeqb (%rdi), %xmm0
    0x7fff5a7e2436 <+22>: pmovmskb %xmm0, %esi
    0x7fff5a7e243a <+26>: andq   $0xf, %rcx
    0x7fff5a7e243e <+30>: orq    $-0x1, %rax
Target 0: (rabin2) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff5a7e2432 libsystem_c.dylib`strlen + 18
    frame #1: 0x00007fff5a83b6f9 libsystem_c.dylib`strdup + 18
    frame #2: 0x000000010038b641 libr_bin.dylib`get_type_code_string(sym="P6A_NAEBVCSbCryptoContext@@PEBEKPEBDK1KPEAEAEAK@ZEA", amount_of_read_chars=0x00007ffeefb9d2f4, str_type_code=0x00007ffeefb9d2e0) at microsoft_demangle.c:1048
    frame #3: 0x000000010038d7df libr_bin.dylib`parse_microsoft_mangled_name(sym="PRF@@3P6A_NAEBVCSbCryptoContext@@PEBEKPEBDK1KPEAEAEAK@ZEA", demangled_name=0x00007ffeefb9d3d8) at microsoft_demangle.c:1119
    frame #4: 0x000000010038d5f9 libr_bin.dylib`microsoft_demangle(demangler=0x000000012345c390, demangled_name=0x00007ffeefb9d3d8) at microsoft_demangle.c:1436
    frame #5: 0x00000001002b18cb libr_bin.dylib`r_bin_demangle_msvc(str="?PRF@@3P6A_NAEBVCSbCryptoContext@@PEBEKPEBDK1KPEAEAEAK@ZEA") at demangle.c:117
    frame #6: 0x000000010039fc09 libr_bin.dylib`print_gvars(pdb=0x00007ffeefb9d598, img_base=0, format=100) at pdb.c:1121
    frame #7: 0x000000010019e01c libr_core.dylib`bin_pdb(core=0x00007ffeefb9d910, mode=100) at cbin.c:1156
    frame #8: 0x000000010019a3fe libr_core.dylib`r_core_bin_info(core=0x00007ffeefb9d910, action=8192, mode=0, va=1, filter=0x00007ffeefbff0f0, chksum=0x0000000000000000) at cbin.c:3441
    frame #9: 0x0000000100003949 rabin2`main(argc=3, argv=0x00007ffeefbff198) at rabin2.c:1083
    frame #10: 0x00007fff5a792115 libdyld.dylib`start + 1
    frame #11: 0x00007fff5a792115 libdyld.dylib`start + 1
(lldb) f 2
frame #2: 0x000000010038b641 libr_bin.dylib`get_type_code_string(sym="P6A_NAEBVCSbCryptoContext@@PEBEKPEBDK1KPEAEAEAK@ZEA", amount_of_read_chars=0x00007ffeefb9d2f4, str_type_code=0x00007ffeefb9d2e0) at microsoft_demangle.c:1048
   1045         }
   1046     }
   1047
-> 1048     *str_type_code = strdup (type_code_str.type_str);
   1049     *amount_of_read_chars = state.amount_of_read_chars;
   1050
   1051 get_type_code_string_err:

looks OOM to me too.

[lowlyw]

unless thre's something funky with the the type parsing thing earlier in that, will dig more

[EvanCarroll]

Looks like it's using 6.7 GB,

ps aux | grep -i rabin2
ecarroll  4948 99.7 34.2 66955724 5561364 pts/4 S+  22:22   4:30 rabin2 -P ./sqllang.pdb

The machine itself 16 GB of memory. Seems the segfault is unrelated. Ran it three times.

[32694.600682] rabin2[4112]: segfault at 0 ip 00007f4a9dd59476 sp 00007ffc49c4e738 error 4 in libc-2.26.so[7f4a9dcb1000+1d6000]
[32923.709824] rabin2[4280]: segfault at 0 ip 00007f377da68476 sp 00007ffdcfd41bc8 error 4 in libc-2.26.so[7f377d9c0000+1d6000]
[33267.621499] rabin2[4948]: segfault at 0 ip 00007f1a17ebe476 sp 00007ffd37679308 error 4 in libc-2.26.so[7f1a17e16000+1d6000]

[riverar]

My machine is still chewing through this PDB; I suspect it's similar to another complaint in #9300 (600mb+ pdb) in that there's poor support for large PDBs in general. We'll need to prioritize optimizing the pdb parser.

[riverar]

@XVilka You marked this as 'regression'; did R2 ever handle large PDBs correctly?

[radare]

Skuater have a fix for this

On 14 Feb 2018, at 18:24, Rafael Rivera [e-mail] wrote:

@XVilka You marked this as 'regression'; did R2 ever handle large PDBs correctly?

—
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]

-> 1048 *str_type_code = strdup (type_code_str.type_str);
<- is this a null deref? can you check with a debugger?

[EvanCarroll]

DLL uploaded in this thread https://github.com/radare/radare2/issues/9385#issuecomment-365703884

https://github.com/radare/radare2/files/1725227/sqllang.dll.zip

[radare]

funnily r2 takes forever to parse this when compiled with asan

On 14 Feb 2018, at 00:38, Evan Carroll [e-mail] wrote:

Using the same information about build and system here https://github.com/radare/radare2/issues/9385..

Download

wget http://msdl.microsoft.com/download/symbols/sqllang.pdb/40D5A1EFAD844ABFA5A689F2E49153E12/sqllang.pdb
Sum

md5sum /tmp/sqllang.pdb 3e1007a0bd83d5c1df6015f15fe1b714 /tmp/sqllang.pdb
$ rabin2 -P /tmp/sqllang.pdb
Segmentation fault (core dumped)
—
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/9387, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lmq1cZ86wmGj_DIJUwCDKwMZIx1Wks5tUhzpgaJpZM4SEkzX.

[EvanCarroll]

@radare do you have a link for it (when you say he has a fix). I didn't see a PR https://github.com/radare/radare2/pulls?utf8=✓&q=is%3Apr+author%3Askuater+

[XVilka]

For me it shows too big string length in libr/bin/mangling/microsoft_demangle.c function copy_string(), value type_code_str->type_str_len:
` mangling/microsoft_demangle.c:126:66: runtime error: left shift of 1093270872 by 1 places cannot be represented in type 'int'

[radare]

@XVilka do you wanna try to make a blind fix here?

[XVilka]

Checking it

[XVilka]

@riverar I fixed the issue (and memory consumption), but if you check the code of the libr/bin/mangling/microsoft_demangler.c it is awful and super ineffective. If you want to improve it - you can play with profiler and optimize it. This 60Mb file loads about 10min on my machine, surely we can do better.

[riverar]

@XVilka Awesome, thanks! Will play with it indeed. cc: @EvanCarroll can you give this a spin and confirm?

[EvanCarroll]

Yep, seems to work now. It's dog slow but it's not segfaulting. Also super slow to run something like idpi~search

[radare]

Performance is always a 2nd step :) want to profile or send a pr improving it?

On 7 Mar 2018, at 16:51, Evan Carroll [e-mail] wrote:

Yep, seems to work now. It's dog slow but it's not segfaulting. Also super slow to run something like idpi~search

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.