DumpStackObjects doesn't seem to work if the thread is on the alternate signal stack

[AndyAyersMS]

Description

I was looking at a linux runtime triggered crashdump. The thread that triggered the dump is in the signal handling code, running on the alternate stack, and !dso for that thread only seems to enumerate references in the signal context or something.

Configuration

Windbg using relatively recent sos, linux crashdump (available if needed).

cc @hoyosjs

[steveisok]

At a minimum, I think we can add to our docs on how to better stitch the alternate stack together.

[leculver]

Resurrecting this old issue. Andy, do you have a good way to generate a crash on the alternate stack? It's tough to build a fix for this without being able to do that. Or do you just happen to have that old crash dump from a year and a half ago?

[leculver]

Nevermind, I was able to reproduce it with this:

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;

// This repro triggers a StackOverflowException via infinite recursion.
// On Linux, the SIGSEGV handler for stack overflow runs on the alternate
// signal stack (set up by CoreCLR via sigaltstack). When createdump captures
// the thread context, the SP should point to the handler stack, not the
// normal thread stack. This is the exact scenario described in issue #4814.
//
// Objects are created in Main and passed through a NoInlining wrapper so
// that stack references to them remain in Main's frame (at the stack base)
// while the recursion fills the rest of the stack downward.

public class ImportantObject
{
    public string Name { get; set; }
    public int Value { get; set; }
    public override string ToString() => $"ImportantObject({Name}, {Value})";
}

public class Program
{
    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
    static void InfiniteRecursion(int depth)
    {
        Span<byte> buffer = stackalloc byte[256];
        buffer[0] = (byte)(depth & 0xFF);
        InfiniteRecursion(depth + 1);
    }

    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
    static void StartRecursion(
        ImportantObject obj1,
        ImportantObject obj2,
        List<ImportantObject> list)
    {
        // These parameters are on this frame's stack. The NoOptimization
        // attribute prevents the JIT from eliminating them before the call.
        InfiniteRecursion(0);

        // Unreachable but ensures the JIT keeps parameters alive
        Console.WriteLine(obj1);
        Console.WriteLine(obj2);
        Console.WriteLine(list.Count);
    }

    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
    static void Main(string[] args)
    {
        // Create managed objects we want to find with !dso
        var obj1 = new ImportantObject { Name = "FindMeOnStack", Value = 42 };
        var obj2 = new ImportantObject { Name = "AlsoFindMe", Value = 100 };
        var list = new List<ImportantObject> { obj1, obj2 };

        Console.WriteLine($"Created objects: {obj1}, {obj2}");
        Console.WriteLine($"List count: {list.Count}");
        Console.WriteLine("About to trigger stack overflow via infinite recursion...");
        Console.Out.Flush();

        // Pass objects as parameters so they remain as stack references
        // in both Main's frame and StartRecursion's frame.
        StartRecursion(obj1, obj2, list);
    }
}

Fixed in #5723.