Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create CoreCLR tests for verifying the stack overflow stack trace printing #32203

Closed
janvorli opened this issue Feb 13, 2020 · 3 comments · Fixed by #35667
Closed

Create CoreCLR tests for verifying the stack overflow stack trace printing #32203

janvorli opened this issue Feb 13, 2020 · 3 comments · Fixed by #35667

Comments

@janvorli
Copy link
Member

The tests should verify that at stack overflow caused by both probing and real stack overflow from one or more threads at the same time prints expected stack trace.

@janvorli janvorli added this to the 5.0 milestone Feb 13, 2020
@janvorli janvorli self-assigned this Feb 13, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Feb 13, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Feb 24, 2020
@yyjdelete
Copy link

@janvorli
When try to debug an stackoverflow in my code today, I found this(#32167) makes #10539 become worse when SOF happen outside main thread.(maybe related to #11677?)

For netcoreapp3.1, it used to get output:"Stack overflow" + returncode:0xC00000FD(stack overflow) when SOF without debugger, and output:"Stack overflow" + returncode:0xC0000005(access violation) when debugger is attached and SOF is happen outside main thread.
But in nightly builds of 5.0, it always lead to an output:"Stack overflow"(still without stack) + returncode:`0xC0000005(access violation) when SOF happen outside main thread even without an debuger attached.

netcoreapp 0.async without debugger 0.async with debugger 1.sync 2.background thread 3.thread pool 4.foreground thread
3.1 0xC00000FD 0xC0000005 0xC00000FD the same as async the same as async the same as async
5.1(nightly) 0xC0000005 0xC0000005 0xC00000FD with stack the same as async the same as async the same as async

simple test code

using System;
using System.Runtime.CompilerServices;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApp2
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            switch (args.Length)
            {
                case 0:
                    Console.WriteLine("SOF in async");
                    SOFAsync().Wait();
                    break;
                case 1:
                    Console.WriteLine("SOF in sync");
                    SOF();
                    break;
                case 2:
                    Console.WriteLine("SOF in background");
                    new Thread(() => SOF()) { IsBackground = true }.Start();
                    Thread.Sleep(1000);
                    break;
                case 3:
                    Console.WriteLine("SOF in thread pool");
                    ThreadPool.QueueUserWorkItem(state => SOF());
                    Thread.Sleep(1000);
                    break;
                case 4:
                    Console.WriteLine("SOF in foreground");
                    new Thread(() => SOF()) { IsBackground = false }.Start();
                    Thread.Sleep(1000);
                    break;
                default:
                    Console.WriteLine("Unknown mode: " + args.Length);
                    break;
            }
        }

        private static async Task SOFAsync()
        {
            await Task.Delay(100);
            SOF();
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        private static void SOF()
        {
            SOF();
        }
    }
}

@janvorli
Copy link
Member Author

@yyjdelete thank you for letting me know, I'll try your sample to see what's wrong. When I was testing it, I've tested stack overflow on both the main thread and also on many secondary threads. Both cases worked for me, generating a stack trace.

@janvorli
Copy link
Member Author

janvorli commented Mar 5, 2020

@yyjdelete I've found what's wrong when running your test case. We get out of stack again when trying to walk the stack and dump the trace. It seems that the async machinery or something else in your change different from my test has made a difference that flipped it over the edge.
I have tried to lower the stack usage during the stack overflow handling and I was able to make it work for all five cases of your test. But I need to spend more time on it.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants