变更摘要

本 PR（[Profiling]fix application path）主要针对 Profiling 模块中应用路径（application path）的处理逻辑进行修复：移除了 Application::GetAppPath 的声明与实现，并在 Application::ResolveAppCmd 中删除了通过 GetAppPath 提取应用路径以及对路径进行 Utils::IsSoftLink 软链接校验的相关逻辑，同时同步清理了对应的单元测试。

主要改动

• 移除 GetAppPath 函数实现：在 src/msprof/collector/dvvp/app/application.cpp 中删除了 Application::GetAppPath 的完整实现（包括空参数返回空串、按 Utils::IsAppName 判断取 paramsCmd[0] 或 paramsCmd[1] 的逻辑）。
• 删除 ResolveAppCmd 中的路径校验逻辑：在 Application::ResolveAppCmd 中移除对 GetAppPath 的调用、appPath 为空的失败返回，以及 Utils::IsSoftLink 软链接检查（含对应的 MSPROF_LOGE 错误日志）。
• 移除 GetAppPath 声明：在 src/msprof/collector/dvvp/app/application.h 中删除 static std::string GetAppPath(std::vector<std::string> paramsCmd); 的私有方法声明。
• 清理对应单元测试：在 test/ut/msprof/app/test/application_utest.cpp 中删除 GetAppPath 测试用例及 LaunchApp 测试中对 Utils::IsSoftLink 的 mock 桩设置。

代码审查

✅ 未发现问题

Thanks for your pull-request.
The full list of commands accepted by me can be found at here.
You can get sig-info at here.
You can self-configure the PR merge rules for this repository. For more details, please refer to Here.
For more, you also can visit HICANN.

PR Approval Progress

✅ Congratulations! All modules have met the lgtm and approve requirements.

Module Approval Details

💡 Tip:

• Committer can comment /approve or /lgtm
• Commenting /approve implies both code review (lgtm) and intent to merge (approve)

CLA Signature Pass

z296249221, thanks for your pull request. All authors of the commits have signed the CLA. 👍

compile

流水线任务触发成功
任务链接 [497dfce5b17f4d848b772d87704fd7d4][流水线指导]

[2026-08-19 11:35:33]    CI执行结束

/lgtm

@zhuliangying

MR 512 代码审查

变更概述

本 MR 移除了 Application::GetAppPath() 函数及其相关的软链接检查逻辑，涉及：

• 删除 GetAppPath() 函数实现（application.cpp）
• 删除函数声明（application.h）
• 删除对应的单元测试（application_utest.cpp）
• 在 ResolveAppCmd() 中移除对 GetAppPath() 的调用和软链接校验

潜在问题

1. 🔴 关键安全检查被移除

问题描述：

// 被移除的代码
if (analysis::dvvp::common::utils::Utils::IsSoftLink(appPath)) {
    MSPROF_LOGE("app_dir(%s) is soft link.", Utils::BaseName(appPath).c_str());
    return PROFILING_FAILED;
}

风险：

• 软链接检查可能是出于安全考虑（防止符号链接攻击、路径遍历等）
• 如果应用路径允许软链接，可能导致用户通过软链接绕过权限检查或指向意外位置
• 这种安全检查的移除需要明确的需求或安全评审支持

建议：

1. 在 PR 描述中说明为什么软链接检查不再需要
2. 如果是因为检查逻辑错误（如标题所说"错误把 -m 识别成路径"），应该修复检查逻辑而不是完全移除
3. 如果确实不需要，请确认是否有其他地方进行了等效的安全检查

2. ⚠️ 空路径检查缺失

问题描述：
原代码中 GetAppPath() 会提取并返回应用路径，ResolveAppCmd() 随后检查：

std::string appPath = GetAppPath(paramsCmd);
if (appPath.empty()) {
    MSPROF_LOGE("app_dir is empty.");
    return PROFILING_FAILED;
}

移除后，代码直接使用 paramsCmd[0]：

cmd = GetCmdString(paramsCmd[0]);
if (cmd.empty()) {
    MSPROF_LOGE("app_dir(%s) is not valid.", Utils::BaseName(paramsCmd[0]).c_str());
}

分析：

• GetAppPath() 的逻辑是：如果 paramsCmd[0] 是应用名（如 bash、python），返回它；否则如果有第二个参数，返回 paramsCmd[1]
• 这个提取逻辑对于处理 -m 参数等场景可能确实有问题（与 PR 标题吻合）
• 但移除后是否正确处理了所有场景？特别是当 paramsCmd[0] 是类似 bash -c ... 这样的命令时

建议：

• 补充单元测试覆盖 --application 参数与 -m 参数组合的场景
• 确认 GetCmdString() 能正确处理所有原来 GetAppPath() 处理的情况

3. 📋 测试覆盖度降低

问题描述：

• 删除了 GetAppPath 的单元测试（18 行）
• 删除了 LaunchApp 测试中的 IsSoftLink mock

建议：

• 虽然移除了函数，但应该增加测试验证移除后的逻辑仍然正确
• 特别是验证修复的问题（-m 被错误识别为路径）不再出现
• 建议添加回归测试：

  TEST_F(PROF_APPLICATION_TEST, ApplicationParamWithDashM) {
      // 验证 -m 参数不会被当作路径处理
  }
  

代码质量

✅ 代码移除干净，没有留下死代码
✅ 相关的头文件声明同步更新
✅ 单元测试同步清理

总体评估

需要澄清：

1. 软链接检查移除的安全影响评估
2. 原问题的详细复现场景（-m 如何被误识别）
3. 修复后是否有端到端测试验证问题已解决

风险等级：🟡 中等

• 移除安全检查需要谨慎
• 逻辑简化可能遗漏边界场景

/approve