StackTrace for an exception in case of inlining, framework methods, and async

[petrroll]

Hi, I have some understanding how stack traces work and how it might interact with async/await, scheduling continuations on thread pool, inlining, and Task unobserved exceptions, but I'm not exactly sure how it all works together.

So imagine a scenario. There's a task kicked off that is made of an async method AAsync(...) the result of which is never awaited, i.e. any exception is unobserved.

As part of this async method another async method is called, let's call it BAsync(...), a sync framework method, let's say .WaitAsync(....) is called. It's in a context where inlining seems plausible. The internals of the WaitAsync method throws an exceptions (let's say NRE, due to it not being thread safe).

Let's say we have an handler on unobserved exceptions:

        TaskScheduler.UnobservedTaskException += (object? sender, UnobservedTaskExceptionEventArgs eventArgs) =>
        {
            eventArgs.SetObserved();
            eventArgs.Exception.Handle(ex =>
            {
                // Log the exception, including the stacktrace

That logs the exception. Now let's say the stack trace of the logged exceptions contains only BAsync(...). Is it plausible? I.e. it not containing WaitAsync due to inlining?

What about ASync(...). If the WaitAsync call is after an await, i.e. it's in an continuation part AAsync won't be on real stack and IIRC there's no automatic stack stitching, is that correct?

Would that be different if BAsync was, instead of as part of explicitley started Task, triggered as callback for cancellation token?

Thank you!

[huoyaoyuan]

It's not quite clear about the concepts here. Async/await has little relationship with inlining. Instead, await'd method executes in a total different stack. If you observe the exception in VS debugger, you can see VS concatenates the stack traces for you. The real stack is separated by awaits.

That logs the exception. Now let's say the stack trace of the logged exceptions contains only BAsync(...). Is it plausible? I.e. it not containing WaitAsync due to inlining?

It depends on the implementation of WaitAsync. It can disappear if inlined.

What about ASync(...). If the WaitAsync call is after an await, i.e. it's in an continuation part AAsync won't be on real stack and IIRC there's no automatic stack stitching, is that correct?

Right. The stack stitching is done by debugger that understands async.

Would that be different if BAsync was, instead of as part of explicitley started Task, triggered as callback for cancellation token?

The nature of BAsync would only affect stack trace under BAsync. await within BAsync will cut the stack to not include BAsync.

[petrroll]

Async/await has little relationship with inlining. Instead, await'd method executes in a total different stack

Yes I understand that. I mentioned it just beucase - as you say - it's relevant to stack traces. And I wanted to explicitely point out that I'm not sure if exceptions stack traces possibly don't try to do some clever stack trace postprocessing and stitch things together despite the real stack looking different due to how asyn/await works.

I'd also somwhat expect that async methods ie transformed by roslyn might be in practise essentially uninlinable by default (unless instructed to) due to more complexity and code additions (they ain't simple methods anymore).

It depends on the implementation of WaitAsync. It can disappear if inlined.

Makes sense :). So there's no post stitching to re-include inline methods in callstack in exceptions :).

Right. The stack stitching is done by debugger that understands async.

So it's not done by default by exception stack-trace creation? Only by debugger if it wants to? Makes sense.

The nature of BAsync would only affect stack trace under BAsync. await within BAsync will cut the stack to not include BAsync.

Didn't you mean ASync in the last case?

Thanks for thorough answer btw!

[huoyaoyuan]

I'd also somwhat expect that async methods ie transformed by roslyn might be in practise essentially uninlinable by default (unless instructed to) due to more complexity and code additions (they ain't simple methods anymore).

The real body of async method is just invoking async method builder, which has a good chance to be inlined.

The nature of BAsync would only affect stack trace under BAsync. await within BAsync will cut the stack to not include BAsync.

Didn't you mean ASync in the last case?

Yeah, the method contains continuation (BAsync) will be the new root of stack trace.

[petrroll]

Sure the real body will get inline but the generated state machine method in display class backing the whole thing won't so there'll be one artifact of that method that's not inlined, no?

[huoyaoyuan]

There is also a chance for the state machine to be inlined, but the chance should be lower.