Skip to content

Conversation

@18202781743
Copy link
Contributor

The condition for checking the fallback configuration had a typo
where it incorrectly referenced m_dsgConfig->isInitializeSucceed()
instead of m_fallbackConfig->isInitializeSucceed(). This would cause
the fallback configuration to be incorrectly skipped even when the
DSG configuration initialization failed but the fallback succeeded.
The fix ensures proper fallback logic by using the correct object's
initialization status.

Influence:

  1. Test logging behavior when DSG config initialization fails but
    fallback config succeeds
  2. Verify logging rules are correctly loaded from fallback configuration
    when appropriate
  3. Ensure no regression in normal DSG config loading path
  4. Test various initialization failure scenarios for both config sources

fix: 修复 LogManager 中后备配置条件检查的错误

后备配置的检查条件存在拼写错误,错误地引用
m_dsgConfig->isInitializeSucceed() 而不是
m_fallbackConfig->isInitializeSucceed()。这会导致即使 DSG 配置初始化失
败但后备配置成功时,后备配置也会被错误地跳过。修复通过使用正确对象的初始
化状态来确保正确的后备逻辑。

Influence:

  1. 测试当 DSG 配置初始化失败但后备配置成功时的日志记录行为
  2. 验证在适当情况下从后备配置正确加载日志规则
  3. 确保正常 DSG 配置加载路径没有回归问题
  4. 测试两种配置源的各种初始化失败场景

The condition for checking the fallback configuration had a typo
where it incorrectly referenced `m_dsgConfig->isInitializeSucceed()`
instead of `m_fallbackConfig->isInitializeSucceed()`. This would cause
the fallback configuration to be incorrectly skipped even when the
DSG configuration initialization failed but the fallback succeeded.
The fix ensures proper fallback logic by using the correct object's
initialization status.

Influence:
1. Test logging behavior when DSG config initialization fails but
fallback config succeeds
2. Verify logging rules are correctly loaded from fallback configuration
when appropriate
3. Ensure no regression in normal DSG config loading path
4. Test various initialization failure scenarios for both config sources

fix: 修复 LogManager 中后备配置条件检查的错误

后备配置的检查条件存在拼写错误,错误地引用
了 `m_dsgConfig->isInitializeSucceed()` 而不是
`m_fallbackConfig->isInitializeSucceed()`。这会导致即使 DSG 配置初始化失
败但后备配置成功时,后备配置也会被错误地跳过。修复通过使用正确对象的初始
化状态来确保正确的后备逻辑。

Influence:
1. 测试当 DSG 配置初始化失败但后备配置成功时的日志记录行为
2. 验证在适当情况下从后备配置正确加载日志规则
3. 确保正常 DSG 配置加载路径没有回归问题
4. 测试两种配置源的各种初始化失败场景
@18202781743 18202781743 requested review from BLumia and mhduiy January 14, 2026 02:17
deepin-ci-robot added a commit to linuxdeepin/dtk6core that referenced this pull request Jan 14, 2026
Synchronize source files from linuxdeepin/dtkcore.

Source-pull-request: linuxdeepin/dtkcore#532
@deepin-ci-robot
Copy link
Contributor

deepin pr auto review

这段代码修改是正确的,它修复了一个明显的逻辑错误。

1. 审查结论

修改正确。原代码在 else if 分支中错误地检查了 m_dsgConfig 的初始化状态,而实际上应该检查 m_fallbackConfig 的初始化状态。

2. 详细分析

  • 语法逻辑

    • 修改前else if (m_fallbackConfig && m_dsgConfig->isInitializeSucceed() ...)
      • 这里存在逻辑矛盾。代码意图是进入 m_dsgConfig 不可用或为默认值后的备用逻辑分支(fallback)。
      • 然而,条件判断中却继续检查 m_dsgConfig->isInitializeSucceed()
      • 潜在风险:如果 m_dsgConfig 指针为空(nullptr),或者 m_dsgConfig 未初始化成功,这里会导致空指针解引用崩溃(Segmentation Fault)。
    • 修改后else if (m_fallbackConfig && m_fallbackConfig->isInitializeSucceed() ...)
      • 逻辑正确。在检查 m_fallbackConfig 指针非空后,紧接着检查该对象自身的初始化状态,确保调用 rules()rulesIsDefaultValue() 是安全的。
  • 代码质量

    • 修复后代码逻辑更加清晰,符合“检查谁就使用谁”的一致性原则。
    • 增强了代码的健壮性,防止了因误用指针导致的崩溃。
  • 代码性能

    • 无影响。仅修改了指针指向的成员函数调用,没有引入额外的计算或内存开销。
  • 代码安全

    • 显著提升。修复了可能导致程序崩溃的空指针访问漏洞。

3. 改进建议

虽然这个 Bug 修复是正确的,但为了进一步提高代码质量,建议考虑以下重构方向:

  1. 封装配置检查逻辑
    目前的 if 条件中存在重复的 m_xxxConfig && m_xxxConfig->isInitializeSucceed() 模式。可以将其封装为一个辅助函数或 Lambda 表达式,以提高可读性并减少出错概率。

    // 示例:辅助函数
    bool isConfigValid(ConfigInterface* config) {
        return config && config->isInitializeSucceed();
    }
    
    // 使用时
    if (isConfigValid(m_dsgConfig) && !m_dsgConfig->rulesIsDefaultValue()) {
        var = m_dsgConfig->rules();
    } else if (isConfigValid(m_fallbackConfig) && !m_fallbackConfig->rulesIsDefaultValue()) {
        var = m_fallbackConfig->rules();
    }
    // ...
  2. 智能指针
    如果 m_dsgConfigm_fallbackConfig 是原始指针,建议评估是否可以使用 std::shared_ptrstd::weak_ptr 来管理其生命周期,从而从根源上减少悬空指针或手动内存管理的风险。

  3. 防御性编程
    在调用 rules() 之前,确保 var 有一个默认的初始值,以防所有条件分支都不满足(虽然目前的代码逻辑看起来覆盖了所有情况,但显式的初始化更安全)。

@deepin-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743, BLumia, zccrs

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@zccrs zccrs merged commit 1a99ed4 into linuxdeepin:master Jan 14, 2026
19 of 20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants