如果断点 A 已被命中，则启用断点 B

Posted 2023-02-25

【中文标题】如果断点 A 已被命中，则启用断点 B

【英文标题】：Enable breakpoint B if breakpoint A has been hit

【发布时间】：2011-12-28 16:17:56

【问题描述】：

我经常发现自己在代码中的某处设置断点 A 并在命中该断点时手动启用一个或多个断点。一个典型的情况是我在调试一个单元测试并且不关心前面的测试。

void testAddZeros()

  Number a(0);
  Number b(0);
  Number result = a.add(b);
  assert((a + b) == Number(0))

void testAddOnes()

  Number a(1);
  Number b(1);
  Number result = a.add(b);
  assert((a + b) == Number(2));

void testAddNegativeNumber()

  Number a(1);
  Number b(-1)
  Number result = a.add(b);
  assert((a + b) == Number(0));

想象一下，如果 testAddZeros() 和 testAddOnes() 运行良好，但 testAddNegativeNumber()。在这种情况下，在Number result = a.add(b); 设置断点将是开始调试的自然位置。现在想象错误位于Number::add 深处的某个地方，所以我们对Numbers::add 早期发生的事情并不真正感兴趣。我想要做的是在Numbers::add 内的某处设置一个断点，只有当我在testAddNegativeNumber()-test 内时才会触发。

有没有办法在断点A被命中时自动启用断点B？

【问题讨论】：

你检查过条件断点吗？可能您可以使用断点 A 被命中的条件来启用“条件”断点 B。（在这种情况下，您可能不再需要断点 A）

@ChristiaanV：是的，但我担心在这种情况下条件断点是不够的——至少一般情况下是这样。

您能否展示一个代码示例，您想在哪里使用它？

我唯一能想到的就是使用反射来查找在条件断点内调用的方法。像这样： new StackTrace().GetFrame(1).GetMethod().Name == "testAddNegativeNumber"

【参考方案1】：

即使不更改代码，您也可以获得依赖断点，方法是使用一些全局存储来保存启用依赖断点的标记。

我发现的最容易访问的存储之一是应用域自定义属性。它们可以通过 System.AppDomain.CurrentDomain.GetData 和 SetData 方法访问。

所以在第一个断点上，你定义了一个“当命中”设置：

System.AppDomain.CurrentDomain.SetData("break",true)

在依赖断点上，将命中条件设置为：

System.AppDomain.CurrentDomain.GetData("break") != null

【讨论】：

我想知道这种事情是否适用于跟踪点......现在我知道了。点赞！

在调试 C++ 代码时是否可以做到这一点？

【参考方案2】：

这是我认为你能做的最好的事情，但它似乎太大了，甚至无法尝试，因为它涉及添加一个变量......

string breakpointToStopOn = string.Empty;
Console.WriteLine("HERE"); // You can set breakpoint A here, 
                           // with a condition (right click on the breakpoint, then selectCondition),
                           // that sets breakpointToStopOn = "A"
Console.WriteLine("B"); // and you can set your breakpoint here with this condition
                        // (breakpointToStopOn == "A");  

您实际上无法在 Console.WriteLine("HERE") 行上停止，但您可以启用或禁用断点，这实际上会启用另一个断点。

但请注意，条件断点语句会在调试时严重降低应用的性能。

【讨论】：

虽然这不是我想要的，但我想这是最好的（嗯，唯一的）建议。