3

我正在尝试通过失败的集成测试来调试我观察到的间歇性问题，但似乎被困在岩石和坚硬的地方之间。

某处某处正在创建一个System.Threading.Tasks.Task随后失败并导致未观察到的任务异常。在生成的处理程序中，我可以看到任务 ID 和导致它失败的异常。我煞费苦心地分析了我的代码，甚至遵循了我自己的建议并命名了我所有的任务，但仍然没有找到有问题的任务。我的代码似乎根本没有创建它。

所以我尝试在Task构造函数本身上设置断点。我可以使用函数断点（使用诸如“System.Threading.Tasks.Task.Task(System.Action)”之类的位置）来做到这一点。这有效，调试器中断并向我显示Task该类的程序集。但是，我真正需要做的是将 的 ID 与Task最终Task失败的 ID 相关联。

因此，为此，我尝试Task.Id在跟踪点中输出该属性。但是我收到一条消息，说该方法已优化，因此无法评估表达式。

所以我尝试使用源代码进行调试。我设置了我所有的符号和你有什么，但我尽我所能尝试了一切，但它不起作用。经过大量谷歌搜索后，我发现最新的 .NET 4不支持它。

有人对我如何继续诊断此问题有任何想法吗？

4

4 回答 4

4

好的，我已经找到了这个问题。该错误的细节可能不如我用来查找它的方法有趣，但我将在下面的单独部分中介绍这两者。

问题

这是有问题的代码的一部分：

private static Task<TSuccessor> ThenImpl<TAntecedent, TSuccessor>(Task<TAntecedent> antecedent, Func<Task<TAntecedent>, Task<TSuccessor>> getSuccessor, CancellationToken cancellationToken, TaskThenOptions options)
{
    antecedent.AssertNotNull("antecedent");
    getSuccessor.AssertNotNull("getSuccessor");

    var taskCompletionSource = new TaskCompletionSource<TSuccessor>();

    antecedent.ContinueWith(
        delegate
        {
            var evenOnFaulted = options.HasFlag(TaskThenOptions.EvenOnFaulted);
            var evenOnCanceled = options.HasFlag(TaskThenOptions.EvenOnCanceled);

            if (antecedent.IsFaulted && !evenOnFaulted)
            {
                taskCompletionSource.TrySetException(antecedent.Exception.InnerExceptions));
            }
            else if ((antecedent.IsCanceled || cancellationToken.IsCancellationRequested) && !evenOnCanceled)
            {
                taskCompletionSource.TrySetCanceled();
            }
            else
            {

此方法支持我的Then扩展方法，我在博客中提到了.

除了在我的博客文章中的实现之外，我最近添加了运行“然后继续”的能力，我称之为，即使前面的任务出错：

Task.Factory.StartNew(() => { throw new InvalidOperationException(); })
    .Then(() => Console.WriteLine("Executed"), TaskThenOptions.EvenOnFaulted);

这将导致初始异常被忽略并在控制台上输出“已执行”。但是，问题是我ThenImpl没有观察到原来的异常。为此，我改变了这一行：

if (antecedent.IsFaulted && !evenOnFaulted)

对此：

if (antecedent.Exception != null && !evenOnFaulted)

现在我不明白这个问题。

现在，您可能想知道为什么这很难追查。问题是，我有很多促进高级场景的任务组合方法。这是一个实际的片段，可让您了解所产生的力量：

private Task OnConnectAsync(CancellationToken cancellationToken, object state)
{
    var firstAttempt = true;
    var retryOnFailureTask = TaskUtil
        .RetryOnFailure(
                () => TaskUtil.Delay(firstAttempt ? TimeSpan.Zero : this.reconnectDelay, cancellationToken)
                .Then(
                    x =>
                    {
                        if (!firstAttempt)
                        {
                            Interlocked.Increment(ref this.connectionAttempts);
                        }

                        firstAttempt = false;
                    })
                .Then(x => this.loggerService.Debug("Attempting to connect communications service (attempt #{0}).", this.connectionAttempts), cancellationToken)
                .Then(x => this.communicationsService.ConnectAsync(cancellationToken), cancellationToken)
                .Then(x => this.loggerService.Debug("Successfully connected communications service (attempt #{0}).", this.connectionAttempts), cancellationToken)
                .Then(x => this.communicationsService.AuthenticateAsync(cancellationToken), cancellationToken)
                .Then(x => this.loggerService.Debug("Successfully authenticated communications service (attempt #{0}).", this.connectionAttempts), cancellationToken)
                .Then(x => this.ReviveActiveStreamsAsync(cancellationToken), cancellationToken)
                .Then(x => this.loggerService.Debug("Successfully revived streams (attempt #{0}).", this.connectionAttempts), cancellationToken),
            null,
            cancellationToken);

    return retryOnFailureTask;
}

注意 custom RetryOnFailure、Then和Delay方法。这是我在谈论的一个很好的品味。

当然，这样做的缺点是在问题发生时跟踪问题。我不禁觉得TPL在这方面做得很差。在我看来，每个都Task应该包含有关谁创建它的信息。至少，TPL 中应该有钩子（例如TaskCreated事件），以便开发人员可以用他们自己的调试信息来补充任务。使用 .NET 4.5 可能会改善这种情况 - 不过我正在使用 .NET 4.0。

方法

追查问题的关键是费力地包装Task我创建的每一个TaskCompletionSource，用补充信息包装任何异常。例如，这是ToBooleanTask我事先拥有的扩展方法：

public static Task<bool> ToBooleanTask(this Task task)
{
    var taskCompletionSource = new TaskCompletionSource<bool>();

    task.ContinueWith(
        x =>
        {
            if (x.IsFaulted)
            {
                taskCompletionSource.TrySetException(x.Exception.GetBaseException());
            }
            else if (x.IsCanceled)
            {
                taskCompletionSource.TrySetCanceled();
            }
            else
            {
                taskCompletionSource.TrySetResult(true);
            }
        });

    return taskCompletionSource.Task;
}

这是在进行此更改之后：

public static Task<bool> ToBooleanTask(this Task task)
{
    var taskCompletionSource = new TaskCompletionSource<bool>();

    task.ContinueWith(
        x =>
        {
            if (x.IsFaulted)
            {
                taskCompletionSource.TrySetException(new InvalidOperationException("Failure in to boolean task", x.Exception.GetBaseException()));
            }
            else if (x.IsCanceled)
            {
                taskCompletionSource.TrySetCanceled();
            }
            else
            {
                taskCompletionSource.TrySetResult(true);
            }
        });

    return taskCompletionSource.Task;
}

在这种情况下，我已经有了一个TaskCompletionSource，所以它很简单。在其他情况下，我必须显式创建一个TaskCompletionSource并将任何故障/取消/结果从底层转发Task到TaskCompletionSource.

旁白：您可能想知道ToBooleanTask扩展方法的使用。如果您想实现一个同时处理通用和非通用任务的方法，它非常有用。您可以实现泛型版本，然后调用非泛型重载ToBooleanTask以创建泛型任务，然后将其传递给泛型重载。

一旦我检查了所有可能的罪魁祸首并按照上述补充了它们，我重新运行了我的测试，直到它失败并注意到它确实ToBooleanTask是在创建没有被观察到的任务。因此，我将其修改为：

public static Task<bool> ToBooleanTask(this Task task)
{
    var stackTrace = new System.Diagnostics.StackTrace(true);
    var taskCompletionSource = new TaskCompletionSource<bool>();

    task.ContinueWith(
        x =>
        {
            if (x.IsFaulted)
            {
                taskCompletionSource.TrySetException(new InvalidOperationException("Failure in to boolean task with stack trace: " + stackTrace, x.Exception.GetBaseException()));
            }
            else if (x.IsCanceled)
            {
                taskCompletionSource.TrySetCanceled();
            }
            else
            {
                taskCompletionSource.TrySetResult(true);
            }
        });

    return taskCompletionSource.Task;
}

当失败发生时，这会给我一个完整的堆栈跟踪。我重新运行了我的测试，直到它失败，并且 - 万岁！- 获得了我需要追踪问题的信息：

Failure in to boolean task with stack trace:    at XXX.Utility.Tasks.TaskExtensions.ToBooleanTask(Task task) in C:\XXX\Src\Utility\Tasks\TaskExtensions.cs:line 110
   at XXX.Utility.Tasks.TaskExtensions.Then(Task antecedent, Func`2 getSuccessor, CancellationToken cancellationToken, TaskThenOptions options) in C:\XXX\Src\Utility\Tasks\TaskExtensions.cs:line 199
   at XXX.Utility.Tasks.StateMachineTaskFactory`1.TransitionTo(T endTransitionState, CancellationToken cancellationToken, WaitForTransitionCallback`1 waitForTransitionCallback, ValidateTransitionCallback`1 validateTransitionCallback, PreTransitionCallback`1 preTransitionCallback, Object state) in C:\XXX\Src\Utility\Tasks\StateMachineTaskFactory.cs:line 312
   <snip>

所以我可以看到这是我的Then重载调用之一ToBooleanTask。然后我可以追踪那个确切的代码，问题很快就变得明显了。

不过，这让我很好奇。为什么我最初用名称补充每个任务的方法没有产生任何结果？我尝试恢复我的修复，直接命名由 生成的任务ToBooleanTask，然后重新运行，直到失败。果然，我在调试器中看到了任务名称。很明显，我最初以某种方式错过了命名这个任务。

呸！

于 2012-11-20T15:40:19.650 回答
1

如果任务的数量是可控的，您可以使用 Visual Studio 中的“制作对象 ID”功能来跟踪每个任务：

  • 在任务构造函数的断点中，将任务放入 Watch 窗口。
  • 右键单击监视窗口中的任务并选择“制作对象 ID”。请注意，这会将 1# 放在值的末尾。为每项任务执行此操作。
  • 做你的工作流程。在引发异常的任务中，检查它的编号。
于 2012-11-19T15:00:49.120 回答
0

打破UnobservedTaskException事件并检查Task. 您可以Task在调用堆栈中找到上一级或两级，因为该事件是由TaskExceptionHolder包含私有字段的类引发的m_task。

该Task对象将包含作为其执行的一部分运行的操作。

于 2012-11-19T11:37:29.253 回答
0

如果可能，您可以更改创建任务的代码以使用接受对象的任务构造函数： Task(Action<Object>, Object)

然后，在您创建任务的每个位置，您都可以向它传递一些独特的东西（识别整数、调用堆栈等）

然后，在 UnobservedTaskException 中，您可以检查此日期（存储在 中Task.AsyncState）。

这将帮助您缩小范围是您的任务还是其他任务。

于 2012-11-20T14:22:56.260 回答