aa crash #3021
Comments
|
note, the updated valgrind log |
|
I can't reproduce it in any OS (OpenBSD, Linux, Mac OS X) in all of them I get the following. |
|
I can't reproduce on OS X. Have you tried to purge/clean the building directory/remove capstone/rebuild everything? |
|
Hi, yes make purge, also it does not make sense to test on different OS. (me and you) What are your test conditions? |
|
Have you also removed the capstone directory and rebuild everything? Anyway, I will download a debian 7.8 32 bit vagrant box and test on it. |
|
yes, I did a fresh clone of the repo. Don't know about vagrant, but I tested on an Lenovo L540 :) |
|
edit @ret2libc see chat |
|
I'm able to reproduce on debian 32 bit at commit 19c48e7 |
|
yes I forgot -c "aa" |
|
please test with 19bcaff |
|
Thank you! Can't reproduce in 19bcaff. |
|
think this needs to be reopened file: http://jjdredd.github.io/game.xz |
|
cant reproduce. it just takes a lot of time and memory, but i dont see On 11/07/2015 12:21 PM, Judge_Dredd wrote:
|
|
is this an oomkill in your side? On 11/07/2015 12:21 PM, Judge_Dredd wrote:
|
|
If it gets oom'd with 2,5Gb RAM it's still a bug :) |
|
memory consumption of the code analysis is something to be improved :) but that's not a crash. you can fix this with hardware. i have 32GB of On 11/07/2015 12:30 PM, Judge_Dredd wrote:
|
|
Asan works fine for me too (I didn't wait for the analysis to finish but it didn't segfault). |
|
Haha :D Will try without asan tonight. Asan build should take more memory and be more paranoic on memory accesses.
|
|
Can someone pls confirm this? |
|
I can do some profiling to optimize the memory usage of the r2 code analysis.
|
|
no crash without asan here. But 900MB of ram needed to analyze a 17MB On 11/08/2015 04:19 PM, Judge_Dredd wrote:
|
|
According to massif, main memory usage comes from the Sdb storage when allocating SdbKv structures. This struct contains a fixed size array to avoid unnecessary heap fragmentation for performance reasons: This is a minimum of 255+8+4+8+4 = 285 bytes per key-value pair on 64bit. This can be reduced to something that it's easier to align like if we use pointers for key too. Also, moving the value_len to the end of the struct will allow us to get some better alignment and reduce that struct size. |
|
I'm also surprised by the amount of memory taken by RBin, here's a second run of massif without analyzing the program, the way to optimize this is not that obvious, so i'll take a deeper look later. If anyone wants to share his thoughs/patches you're welcome :)
|
|
The yellow lines are caused by the RFlagItem struct which is really huge for the same reasons. I did a quick change and reduced memory usage from 80MB to 14MB, so I guess we can go this way for the rest of structs containing fixed size arrays :P i guess that performance will be worst for small bins, but better for big ones. because the heap allocator doesnt seems to manage big allocations as well as small ones. |
|
I really don't feel like this is an oom issue. |
|
After dinner i will do all those mem optimizations. So you can try again
|
|
Anyway your backtrace doesnt shows any crash at all. Can you check syslog to confirm that oom thing? Can you also verify the instruction that is prpducing the crash if any? Not just the backtrace and the register values?
|
|
After all the optimizations mentioned done (well, almost all of them) I have managed to reduce the memory consuption of r2 from 630MB to 235MB. All tests are passing. There are still some minor things to be done, but, it will be good if you give it a try and confirm that the issue is gone |
|
The startup memory usage have been also improved from 346MB to 76MB. And it can be lowered to 50 or so. In fact, Just the Sdb change resulted in -150MB. Here there are some screenshots:
|
|
600-700 Mb I can afford, so I'm not out of memory imho. Dump of assembler code for function _int_malloc:
0xb63d9da0 <+0>: push ebp
0xb63d9da1 <+1>: push edi
0xb63d9da2 <+2>: push esi
0xb63d9da3 <+3>: push ebx
0xb63d9da4 <+4>: call 0xb6488e73 <__x86.get_pc_thunk.bx>
0xb63d9da9 <+9>: add ebx,0x123257
0xb63d9daf <+15>: sub esp,0x8c
0xb63d9db5 <+21>: cmp edx,0xffffffdf
=> 0xb63d9db8 <+24>: mov DWORD PTR [esp+0x48],edx
0xb63d9dbc <+28>: ja 0xb63da49c <_int_malloc+1788>
0xb63d9dc2 <+34>: mov ebp,eax
0xb63d9dc4 <+36>: mov eax,DWORD PTR [esp+0x48]
0xb63d9dc8 <+40>: mov DWORD PTR [esp+0x40],0x10
0xb63d9dd0 <+48>: add eax,0xb
0xb63d9dd3 <+51>: mov edx,eax
0xb63d9dd5 <+53>: and edx,0xfffffff8
0xb63d9dd8 <+56>: cmp eax,0x10
0xb63d9ddb <+59>: cmovb edx,DWORD PTR [esp+0x40]
0xb63d9de0 <+64>: cmp edx,DWORD PTR [ebx+0x18e8]
0xb63d9de6 <+70>: mov DWORD PTR [esp+0x40],edx
0xb63d9dea <+74>: ja 0xb63d9e80 <_int_malloc+224> |
=> 0xb63d9db8 <+24>: mov DWORD PTR [esp+0x48],edxWas I really out of stack?? EDIT: Yup, |
|
Yep. How small your stack is? I can reduce this requirement too
|
|
your crash shows that the size of your stack is 64KB. Welcome to 2015 |
|
Try again, i have moved this 8KB buffer from the stack to the heap. |
|
I think it's even less: yeh, I'm from 80's |
morn,
aa crash on ROPGadget testsuite bin:
Greetings
--zlul
valgrind follows:
http://sprunge.us/CIbi
radare2 0.10.0-git 8573 @ linux-little-x86-32 git.0.9.9-471-g9e42daf
commit: 9e42daf build: 2015-07-30
The text was updated successfully, but these errors were encountered: