In-process (.NET, Windows): access violation in copilot_runtime_connection_write when responding to runtime requests

Ouverte
#2,821 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
43/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
csharp, typescript
Domaine
backend, devtools

Piste de recherche

Start by tracing the .NET in-process response path from FfiRuntimeHost.SendFrame through JsonRpc.SendResultResponseAsync, then inspect the native copilot_runtime_connection_write implementation and its connection lifecycle. Try to reproduce on Windows x64 with parallel MCP tool calls using the reported SDK/runtime versions; done means writes either succeed or report a managed error without crashing the host.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

With in-process hosting (RuntimeConnection.ForInProcess()) on Windows x64, the host process dies with an access violation (0xC0000005) inside the native copilot_runtime_connection_write while the .NET SDK writes a response frame. It happens mid-turn in long agent sessions and takes down the whole host application.

Versions

  • GitHub.Copilot.SDK 1.0.16 (runtime 1.0.89) and 1.0.17 (runtime 1.0.93); reproduced on both
  • .NET 10, win-x64, self-contained WPF app, in-process hosting
  • Session config: OnPreToolUse hook (synchronous, returns allow), OnPermissionRequest handler (synchronous allow), OnUserInputRequest, OnElicitationRequest, an HTTP MCP server with many tools, AskUserVariant.Elicitation, a custom provider pointed at a loopback HTTP endpoint

Stack (1.0.17)

Fatal error.
0xC0000005
   at GitHub.Copilot.FfiRuntimeHost.<ConnectionWrite>g____PInvoke|55_0(UInt32, Byte*, UIntPtr)
   at GitHub.Copilot.FfiRuntimeHost.SendFrame(System.ReadOnlySpan`1<Byte>)
   at GitHub.Copilot.JsonRpc+<SendMessageAsync>d__35`1[[System.__Canon, ...]].MoveNext()
   at GitHub.Copilot.JsonRpc+<SendResultResponseAsync>d__46.MoveNext()
   at GitHub.Copilot.JsonRpc.SendResultResponseAsync(System.Text.Json.JsonElement, System.Object, System.Type, System.Threading.CancellationToken)
   at GitHub.Copilot.JsonRpc+<HandleIncomingMethodAsync>d__41.MoveNext()
   at GitHub.Copilot.JsonRpc+<ReadLoopAsync>d__37.MoveNext()
   ...
   at GitHub.Copilot.JsonRpc+<ReadMessageAsync>d__39.MoveNext()
   ...
   at GitHub.Copilot.FfiRuntimeHost+CallbackReceiveStream+<ReadAsync>d__4.MoveNext()
   ...
   at GitHub.Copilot.FfiRuntimeHost+CallbackReceiveStream+<ReadCoreAsync>d__5.MoveNext()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()

On 1.0.16 the same fault came through JsonRpc.SendMessageAsync from CopilotSession.HandlePendingPermissionRequestAsync.

Pattern

Both crashes happened right after the model issued two MCP tool calls in parallel. The host log shows two preToolUse approvals, then two permission-request approvals, then an MCP HTTP call returning 200, and then the fault while writing a response frame back to the runtime. FfiRuntimeHost.SendFrame already holds _lifecycleLock and checks _disposed and _connectionId, so the managed side does not seem to be writing concurrently or after close. The fault appears to be in the native write path.

Frequency: about 1 crash in 15–20 multi-tool conversations when replaying real user sessions (each 1–4 turns, 10–60 tool calls). Single-turn tests and a 40-turn sequential stress run did not reproduce it, so concurrency between parallel tool calls looks like a factor.

Possibly related: on 1.0.16 we also saw one turn hang forever. The session's events.jsonl had hook.start for preToolUse with no matching hook.end, even though our hook returns synchronously.

Expected

A response write to an open connection either succeeds or fails with a managed error. It should never crash the host process.

Happy to run a build with extra native logging if that helps.

Langage dominant
Java
Étoiles
10.7k
Forks
1.5k
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/copilot-sdk

Toutes les issues de github/copilot-sdk

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.