Brian Potchik
Brian Potchik
Yeah I'm not sure if any updates I made would specifically help with the shifts. If I had an example binary I would be more than willing to spend some...
Changing the feature map location to the top, then back to the right resolves the issue. There is a small bug here somewhere which only seems to show up with...
When encountering an address with no code created yet, the debugger could probably use the `GetPreviousFunctionStartBeforeAddress` and `GetNextFunctionStartAfterAddress` APIs, and then request on demand analysis for those specific functions. So...
Thanks for sharing this binary. I've made a couple of changes to help improve analysis for situations where there are many very large functions, as well as non-sensical disassembly. Try...
This setting is enabled by default in `5.1.7610-dev`.
I've found the source of the memory leak. It's in the Tags system. 100GB of tags related allocations. I've added a setting `'analysis.tags.autoGenerate'`which allows you to turn off auto tags...
There have been some attempts to fix the memory leaks related to tags. So far it appears to have helped the issue, and with auto generation of tags enabled this...
It takes around 1.5 hours to finish Phase 1 analysis. Memory increased to around 47GB. We handle this binary much better than initially. Resource utilization after closing looks to be...
There is another related issue in this binary as well. Check address `0x402948` `21 @ 00402948 int32_t var_29c_1 = 0x44` All of these temp stack vars at 29c should be...
One solution here is to keep the segment ranges immutable after the segment object is added. Existing code that consumes the segment map will need to be updated to use...