Skip to content

Add SafeTlsContextHandle and SafeTlsHandle for direct-fd TLS#3

Open
DeagleGross wants to merge 1 commit into
mainfrom
dmkorolev/tls/ssl-handles
Open

Add SafeTlsContextHandle and SafeTlsHandle for direct-fd TLS#3
DeagleGross wants to merge 1 commit into
mainfrom
dmkorolev/tls/ssl-handles

Conversation

@DeagleGross

Copy link
Copy Markdown
Owner

No description provided.

Renamed from SafeSslContextHandle/SafeSslHandle to use Tls prefix
(consistent with TlsCipherSuite and modern .NET naming).

Key changes from original commit:
- SafeTlsContextHandle.Create(SslServerAuthenticationOptions) factory
  replaces individual UseCertificate/SetProtocols/etc. methods
- SafeTlsContextHandle.Create(SslClientAuthenticationOptions) for clients
- Only SetSessionCacheSize/SetSessionTimeout remain as instance methods
  (not yet on the options types)
- SslException removed — uses AuthenticationException for handshake errors,
  IOException for post-handshake I/O errors
- SslSessionCacheMode removed — AllowTlsResume on options covers this
- SslOperationStatus renamed to TlsOperationStatus
- Read/Write throw InvalidOperationException if handshake not completed
- NativeInterop stubs moved to nested static class (not partial Interop)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
DeagleGross pushed a commit that referenced this pull request May 28, 2026
…128163)

> [!NOTE]
> This PR was authored with assistance from GitHub Copilot.

Fixes dotnet#128044.

## Problem

createdump SIGSEGVs on Linux when generating a Heap-type minidump for a
process running interpreted code. The crash reproduces locally with the
`InterpreterStack` DumpTests debuggee and matches the CI failure that
prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary
workaround.

The faulting backtrace is:

```
#0  Thread::IsAddressInStack    threads.cpp:6741
#1  Thread::EnumMemoryRegionsWorker  threads.cpp:6909 (calls IsAddressInStack(currentSP))
#2  Thread::EnumMemoryRegions        threads.cpp
#3  ThreadStore::EnumMemoryRegions
#4  ClrDataAccess::EnumMemDumpAllThreadsStack
dotnet#5  ClrDataAccess::EnumMemoryRegionsWorkerHeap   (HEAP2-only path)
```

## Root cause

`Thread::m_pInterpThreadContext` was declared as a raw
`InterpThreadContext *`. In non-DAC code that's a normal host pointer,
but in
DAC mode the field's value is a target-process address. When
`IsAddressInStack` (a DAC-callable helper) dereferenced
`m_pInterpThreadContext->pStackStart` it read from a target-process
address
as if it were a host address, which faults inside createdump.

## Fix

Change the field type to `PTR_InterpThreadContext` (DPTR), matching the
treatment of other Thread fields like `m_pFrame`. In non-DAC builds
`DPTR(T)` is just `T*`, so there is no overhead or behavior change. In
DAC
builds the read goes through `__DPtr<T>` and marshals correctly from the
target.

Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the
`InterpreterStack` DumpTests debuggee so the Heap path that originally
failed is exercised again.

## Validation

Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump
mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`)
running the `InterpreterStack` debuggee. With this fix applied,
createdump
produces a complete Heap dump (~74 MB) instead of crashing.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant