已关闭
fix: 修复内存问题 #20
fix: 修复内存问题 #20
已关闭
myxuan475创建于 7月25日关闭于 5 天前
myxuan475
myxuan475
7月25日

fix: 修复内存问题

likedislike
当前Pull Request已关闭, 关闭人@myxuan475
openharmony_ci
openharmony_ci成员
7月25日 评论:

感谢提交 Pull Requests!
Thanks for submitting a pull request.

likedislike
openharmony_ciopenharmony_ci成员
7月25日 添加了label:dco检查成功
myxuan475myxuan475
7月25日 关联了issue:fix: 修复内存问题
myxuan475
myxuan475
7月25日 评论:

start build

likedislike
openharmony_ci
openharmony_ci成员
7月25日 评论:

首次触发
门禁构建开始,包含静态检查、代码编译【rntpc_br_rnoh0.82编译】,预计在60分钟内完成,门禁结果会同步发送到注册邮箱。您可以通过如下链接跟踪门禁进展:http://dcp.openharmony.cn/workbench/cicd/detail/6a64866a64650f998b25063f/runlist

likedislike
cpf-manager
cpf-manager7月25日进行代码检视2
harmony/mmkv_storage/src/main/cpp/napi_init.cpp
已过期
@@ -577,1 +575,3 @@
577- 
575+ find_if(mmkvInstances.begin(), mmkvInstances.end(), [&id](MMKV *inst) { return inst != nullptr && inst->mmapID() == id; });
576+ if (it != mmkvInstances.end()) {
577+ delete *it;
cpf-manager
cpf-manager7月25日评论:

【AI-Review】【致命】【基础代码问题】【代码逻辑错误】delete *it 导致 MMKV 内部缓存悬空指针,引发 use-after-free

● 问题:delete *it; 直接释放了 MMKV 对象的内存,但未从 MMKV 的全局实例字典 g_instanceDic 中移除该条目。MMKV 库的 mmkvWithID() 方法在创建实例时会将其缓存到 g_instanceDic(见 MMKV/Core/MMKV_Android.cpp:147-151),后续调用 mmkvWithID 时会优先从字典中查找并返回已缓存的实例。正确的释放方式是调用 MMKV::close()(见 MMKV/Core/MMKV.cpp:335-345),该方法会先从 g_instanceDic 中移除条目,再执行 delete this。

● 影响:触发路径:setupMMKVInstance 被调用时 → delete *it 释放旧 MMKV 对象但 g_instanceDic 仍持有悬空指针 → 紧接着 MMKV::mmkvWithID(id, ...) 从 g_instanceDic 中找到并返回该悬空指针 → 返回的 kv 指向已释放内存 → 后续所有读写操作(setStringMMKV、getStringMMKV 等)均使用该悬空指针 → 导致 use-after-free,可能引发崩溃、数据损坏或未定义行为。

● 建议:将 delete *it; 替换为 (*it)->close();。close() 方法的实现(MMKV/Core/MMKV.cpp:335-345)会在 delete this 之前先从 g_instanceDic 中擦除该条目,确保后续 mmkvWithID 调用不会返回悬空指针。修改后代码:

if (it != mmkvInstances.end()) {
    (*it)->close();
    mmkvInstances.erase(it);
}
likedislike
System
系统消息系统
7月25日 评论:

changed this line on 1fbce250 view diff detail

cpf-manager
cpf-manager7月25日进行代码检视3
harmony/mmkv_storage/src/main/cpp/napi_init.cpp
已过期
@@ -415,7 +415,7 @@ void sortVector(std::vector<std::string> &vec) { std::sort(vec.begin(), vec.end(
415415 
416416static MMKV *getInstance(const std::string &ID) {
417417 auto kv =
418- std::find_if(mmkvInstances.begin(), mmkvInstances.end(), [&ID](MMKV *inst) { return inst->mmapID() == ID; });
418+ std::find_if(mmkvInstances.begin(), mmkvInstances.end(), [&ID](MMKV *inst) { return inst != nullptr && inst->mmapID() == ID; });
419419 if (kv == mmkvInstances.end()) {
420420 return nullptr;
421421 }
@@ -572,10 +572,11 @@ static napi_value setupMMKVInstance(napi_env env, napi_callback_info info) {
572572 auto cryptKey = NValueToString(env, args[2], true);
573573 auto path = NValueToString(env, args[3], true);
574574 auto it =
575- find_if(mmkvInstances.begin(), mmkvInstances.end(), [&id](MMKV *inst) { return inst->mmapID() == id; });
576- if (it != mmkvInstances.end())
577- 
575+ find_if(mmkvInstances.begin(), mmkvInstances.end(), [&id](MMKV *inst) { return inst != nullptr && inst->mmapID() == id; });
576+ if (it != mmkvInstances.end()) {
577+ delete *it;
578578 mmkvInstances.erase(it);
579+ }
579580 MMKV *kv = nullptr;
580581 auto cryptKeyPtr = cryptKey.empty() ? nullptr : &cryptKey;
581582 auto rootPathPtr = path.empty() ? nullptr : &path;
@@ -588,7 +589,7 @@
588589 } catch (const std::exception &e) {
589590 std::cerr << "Caught exception: " << e.what() << std::endl;
590591 }
591592 mmkvInstances.push_back(kv);
cpf-manager
cpf-manager7月25日评论:

【AI-Review】【建议】【基础代码问题】【稳定性问题】nullptr 被推入 mmkvInstances 导致无效条目累积

● 问题:在 setupMMKVInstance 中,当 MMKV::mmkvWithID 抛出异常时(第 588-590 行的 catch 块),kv 保持为 nullptr,但第 592 行仍然执行 mmkvInstances.push_back(kv) 将 nullptr 推入向量。PR 新增的 null 检查(inst != nullptr &&)使得 find_if 在后续调用中跳过这些 nullptr 条目,因此它们永远不会被找到和清理,在向量中持续累积。

● 影响:每次 setupMMKVInstance 因异常失败都会在 mmkvInstances 中新增一个永久的 nullptr 条目,向量持续膨胀。虽然功能上不会崩溃(null 检查保护了 find_if),但属于资源浪费,且使调试更困难。

● 建议:在 push_back 前检查 kv 是否有效,仅当 kv 非 null 时才推入向量和设置索引:

if (kv) {
    mmkvInstances.push_back(kv);
    indexing_enabled[id] = NValueToBool(env, args[4]);
    initIndexForId(id);
}
likedislike
myxuan475
myxuan475
7月25日 评论:

已修改

System
系统消息系统
7月25日 评论:

changed this line on 75d4dae2 view diff detail

myxuan475myxuan475
7月25日 强制推送  1 个提交:1fbce250-fix: 修复内存问题
openharmony_ci
openharmony_ci成员
7月25日 评论:

监测到PR: https://gitcode.com/CPF-RN/rntpc_react-native-mmkv-storage/merge_requests/20 代码有更新,当前正在执行的门禁任务已自动中止,如有需要,可重新触发

likedislike
openharmony_ci
openharmony_ci成员
7月25日 评论:

感谢提交 Pull Requests!
Thanks for submitting a pull request.

likedislike
myxuan475
myxuan475
7月25日 评论:

start build

likedislike
openharmony_ci
openharmony_ci成员
7月25日 评论:

本地或库上代码有更新,全量重新构建,重置所有关联PR的验证状态
门禁构建开始,包含静态检查、代码编译【rntpc_br_rnoh0.82编译】,预计在60分钟内完成,门禁结果会同步发送到注册邮箱。您可以通过如下链接跟踪门禁进展:http://dcp.openharmony.cn/workbench/cicd/detail/6a648bc964650f998b2718af/runlist

likedislike
openharmony_ciopenharmony_ci成员
7月25日 添加了label:编译成功
openharmony_ciopenharmony_ci成员
7月25日 添加了label:静态检查成功
openharmony_ciopenharmony_ci成员
7月25日 通过测试
openharmony_ci
openharmony_ci成员
7月25日 评论:

代码门禁通过
您可以通过如下链接查看门禁报告:http://dcp.openharmony.cn/workbench/cicd/detail/6a648bc964650f998b2718af/runlist

静态检查:

# check type result report
1 codeCheck pass >>>

编译测试:
# Device build result package
1 rntpc_br_rnoh0.82 success >>>

likedislike
myxuan475myxuan475
7月25日 测试状态已重置,测试人: openharmony_ci
myxuan475myxuan475
7月25日 强制推送  1 个提交:75d4dae2-fix: 修复内存问题
myxuan475
myxuan475
7月25日 评论:

start build

likedislike
openharmony_ciopenharmony_ci成员
7月25日 删除了label:编译成功
openharmony_ciopenharmony_ci成员
7月25日 删除了label:静态检查成功
openharmony_ci
openharmony_ci成员
7月25日 评论:

代码有更新,重置PR验证状态

likedislike
openharmony_ci
openharmony_ci成员
7月25日 评论:

本地或库上代码有更新,全量重新构建,重置所有关联PR的验证状态
门禁构建开始,包含静态检查、代码编译【rntpc_br_rnoh0.82编译】,预计在60分钟内完成,门禁结果会同步发送到注册邮箱。您可以通过如下链接跟踪门禁进展:http://dcp.openharmony.cn/workbench/cicd/detail/6a6494ed64650f998b2a5f06/runlist

likedislike
openharmony_ci
openharmony_ci成员
7月25日 评论:

感谢提交 Pull Requests!
Thanks for submitting a pull request.

likedislike
cpf-manager
cpf-manager7月25日进行代码检视1
harmony/mmkv_storage/src/main/cpp/napi_init.cpp
@@ -594,3 +596,4 @@
596+ }
594597 }
595598 
596599 return BoolToNValue(env, true);
cpf-manager
cpf-manager7月25日评论:

【AI-Review】【建议】【基础代码问题】【验证问题】setupMMKVInstance 创建失败时返回值不准确

● 问题:setupMMKVInstance 函数在 MMKV 实例创建失败(kv 为 null)时,仍然返回 true。触发路径:当 MMKV::mmkvWithID() 抛出异常(被第590行 try-catch 捕获后 kv 保持 null)或返回 null(如 g_instanceLock 未初始化时 MMKV/Core/MMKV_Android.cpp:141 返回 null)时,第592行的 if (kv) 守卫正确地阻止了将 null 指针加入 mmkvInstances,但函数最终执行到第599行 return BoolToNValue(env, true) 仍返回 true。JS 侧会认为 setup 成功,后续对该 ID 的操作(getStringMMKV、setStringMMKV 等)调用 getInstance(id) 返回 null 后静默返回 undefined,导致用户数据未持久化而不知情。

● 影响:建议。当 MMKV 实例创建失败时,JS 侧无法感知失败,可能导致用户数据丢失且无任何错误提示。

● 建议:将返回值改为反映实际创建结果。可在 if (!id.empty()) 块前声明 bool result = false;,在 if (kv) 块内设置 result = true;,最终返回 BoolToNValue(env, result);。这样 JS 侧能正确感知 setup 是否成功,便于进行错误处理。

likedislike
openharmony_ciopenharmony_ci成员
7月25日 添加了label:编译成功
openharmony_ciopenharmony_ci成员
7月25日 添加了label:静态检查成功
openharmony_ciopenharmony_ci成员
7月25日 通过测试
openharmony_ci
openharmony_ci成员
7月25日 评论:

代码门禁通过
您可以通过如下链接查看门禁报告:http://dcp.openharmony.cn/workbench/cicd/detail/6a6494ed64650f998b2a5f06/runlist

静态检查:

# check type result report
1 codeCheck pass >>>

编译测试:
# Device build result package
1 rntpc_br_rnoh0.82 success >>>

likedislike
myxuan475myxuan475
5 天前 关闭了 pull request