问题

Question

我正在尝试调试我通过失败的集成测试观察到的间歇性问题，但似乎陷入了摇滚和硬地之间。

某个地方正在创建一个随后失败的System.Threading.Tasks.Task并导致未观察到的任务异常。在结果处理程序中，我可以看到任务ID和导致它失败的异常。我已经精心分析了我的代码甚至是followed my own advice and named all my tasks，但仍然没有找到违规的任务。似乎我的代码根本就没有创建它。

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

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

所以我尝试用source调试。我设置了所有符号和你有什么，但我尽我所能，但它没有用。经过大量的谷歌搜索后，我发现最新的.NET 4上有isn't supported。

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

Answer 1

好的，我已经找到了这个问题。这个bug的具体细节可能没有我用来找到它的方法那么有趣，但我将在下面的单独部分中介绍它们。

问题

以下是有问题的代码的一部分：

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扩展方法I've blogged about。

除了在我的博客文章中的实现之外，我最近添加了运行“then continuation”的功能，就像我所说的那样，即使先前的任务有问题：

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

这将导致忽略初始异常并在控制台上输出“Executed”。但问题是我的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;
}

请注意自定义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的{{1}}重载之一。然后，我可以追溯到那些确切的代码，问题很快就会明显。

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

呼！

Answer 2

如果任务数量可管理，您可以使用Visual Studio中的“创建对象ID”功能来跟踪每个任务：

在任务构造函数的断点中，将任务放入Watch窗口。
在监视窗口中右键单击任务，然后选择“生成对象ID”。请注意，这会在值的末尾放置1＃。为每项任务执行此操作。
做你的工作流程。在抛出异常的任务中检查它具有的数字。

Answer 3

中断UnobservedTaskException事件并检查Task的私有字段。您可以在调用堆栈中找到Task一个或两个级别，因为事件是由包含私有字段TaskExceptionHolder的{{1}}类引发的。

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

Answer 4

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

然后，在您创建任务的每个位置，您可以传递一些唯一的东西（标识整数，调用堆栈等）。

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

这可以帮助您缩小它是您的任务还是其他任务。

调试失败的，未观察到的TPL任务

4 个答案:

问题

方法