疑似内存泄漏问题

[atrueman2021]

内存在逐步增加，内存插桩显示ctypes每次都会新增很多字节，还不清楚是什么原因导致的。

情景1：
for i in range(100000):
with objc.autorelease_pool():
print(i)
time.sleep(0.01)

情景2:
data = pyobj2nsobj(emu, XXX)
for i in range(100000):
o = objc.find_class("XXSDK").call_method("sharedInstance").call_method("XXXSign:", data).call_method( "UTF8String")
print(o)

[sledgeh4w]

你使用的是什么操作系统呢？我这边做了测试，对于情景1，在前期（由于 sleep 的原因，这个时间久到一般等不到结束）很长一段时间内存确实会逐步增加，但一旦到了某个临界点，内存就会维持在一个水平不再上升。具体原因我也无法解释，只能说可能是 Unicorn 内部的某种实现导致的，你可以移除 sleep 之后再测试一下。

[sledgeh4w]

我知道问题原因了，应该不属于泄漏，内存上升是由于 Unicorn 底层的 TB 缓存导致的，你可以在每次调用后执行下面这行代码来清除缓存：

emu.uc.ctl_flush_tb()

但是这样会对性能有影响。

[atrueman2021]

感谢你的回复，从测试结果看来看确实是tbc导致的。能否讲下你定位这个问题的思路呢，以及在使用chomper遇到疑难杂症时我们应该从哪些方面去排查定位问题。

[sledgeh4w]

感谢你的回复，从测试结果看来看确实是tbc导致的。能否讲下你定位这个问题的思路呢，以及在使用chomper遇到疑难杂症时我们应该从哪些方面去排查定位问题。

内存上升的情况我之前有注意到只是没有深究，因为我在跑的一些程序并没有 OOM，怀疑 TBC 是因为之前出现过另一个问题 #185 也是 TBC 导致的。

对于模拟执行的时候遇到的一些问题，首先判断是不是缺少上下文导致（例如某些全局变量未初始化等），可以通过监控运行过程中使用到的静态地址来分析。再看问题是出在系统库中还是目标程序中。如果对系统 API 的调用是正确的还是出错，那基本就是框架的问题，直接上报到仓库，我会来修复。如果是目标程序传了异常参数给系统 API（例如程序把一个空值作为地址传了过去），那就溯源是什么原因导致了异常值的产生，根据具体原因再看怎么修复。

[atrueman2021]

像如下函数getSign被调用数万次后，开始一切正常，后面会全部报出：Invalid memory mapping (UC_ERR_MAP)，这可能是什么原因导致的呢？内存稳定后没有明显波动，我尝试将栈空间扩大了些，但似乎只是延缓了UC_ERR_MAP出现时间。

def getSign(data: Dict[str, Any]) -> Dict[str, str]:
with objc.autorelease_pool():
signContent = pyobj2nsobj(emu, data["signContent"])
result = XXXSDK.call_method("getSign:", signContent)
sign_str_ptr = result.call_method("objectForKey:", sign).call_method("UTF8String")
ret_val = {"sign": emu.read_string(sign_str_ptr)}
return ret_val

[sledgeh4w]

你可以 email 发我一下程序，我运行起来看一下。

[atrueman2021]

你可以 email 发我一下程序，我运行起来看一下。

已发送sledgeh4w@gmail.com