FS#5369 - Laden von Projekt führt zu Deadlock in Kernel
Wenn man das Projekt aus folgendem Post https://forum.dmxcontrol-projects.org/index.php?thread/17677-dmxc-3-3-0-rc3-projekte-aus-der-3-3-rc2-k%C3%B6nnen-nicht-geladen-werden/&postID=145857#post145857 in DMXC 3.3.0 RC3 (ohne Debugger) lädt, dann fliegen (fast immer) im Umbra und der GUI einige Fehler nach dem Schema
Umbra:
2024-08-01 01:36:20,568 [93] ERROR Grpc.AspNetCore.Server.ServerCallHandler - Error when executing service method 'GetParameters'. System.Threading.Tasks.TaskCanceledException: A task was canceled. at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in P:\Sources\Lumos\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 371 at Umbra.Bridge.UnaryToStreamBridge`2.ClientSideTaskProvideClient(TRequest request, UmbraClient u, Nullable`1 deadline, CancellationToken contextCancellationToken) in P:\Sources\Lumos\Umbra\src\Bridge\UnaryToStreamBridge.cs:line 391 at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle) at Grpc.Shared.Server.UnaryServerMethodInvoker`3.AwaitInvoker(Task`1 invokerTask, GrpcActivatorHandle`1 serviceHandle) at Grpc.AspNetCore.Server.Internal.CallHandlers.UnaryServerCallHandler`3.HandleCallAsyncCore(HttpContext httpContext, HttpContextServerCallContext serverCallContext) at Grpc.AspNetCore.Server.Internal.CallHandlers.ServerCallHandlerBase`3.<HandleCallAsync>g__AwaitHandleCall|8_0(HttpContextServerCallContext serverCallContext, Method`2 method, Task handleCall)
GUI:
2024-08-01 01:36:20,547 [4] ERROR Lumos.GUI.Net.gClient.Parameter_gClient - Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED" --- Ende der internen Ausnahmestapelüberwachung --- bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) bei Grpc.Core.Internal.AsyncCall`2.UnaryCall(TRequest msg) in /var/local/git/grpc/src/csharp/Grpc.Core/Internal/AsyncCall.cs:Zeile 78. bei Grpc.Core.Calls.BlockingUnaryCall[TRequest,TResponse](CallInvocationDetails`2 call, TRequest req) in /var/local/git/grpc/src/csharp/Grpc.Core/Calls.cs:Zeile 46. bei Grpc.Core.DefaultCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request) in /var/local/git/grpc/src/csharp/Grpc.Core/DefaultCallInvoker.cs:Zeile 46. bei Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx) in /_/src/Grpc.Core.Api/Interceptors/InterceptingCallInvoker.cs:Zeile 53. bei Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation) in /_/src/Grpc.Core.Api/ClientBase.cs:Zeile 205. bei Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request) in /_/src/Grpc.Core.Api/Interceptors/InterceptingCallInvoker.cs:Zeile 50. bei UmbraClient.ParameterClient.ParameterClientClient.GetParameters(GetParametersRequest request, CallOptions options) in P:\Sources\Lumos\LumosProtobuf\obj\Debug\netstandard2.0\Client\ParameterClientGrpc.cs:Zeile 164. bei UmbraClient.ParameterClient.ParameterClientClient.GetParameters(GetParametersRequest request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) in P:\Sources\Lumos\LumosProtobuf\obj\Debug\netstandard2.0\Client\ParameterClientGrpc.cs:Zeile 159. bei Lumos.GUI.Net.gClient.Parameter_gClient.<ParametersCore>d__3.MoveNext() in P:\Sources\Lumos\LumosGUI\src\Net\gClient\Parameter_gClient.cs:Zeile 50.
Lädt man dieses Projekt, wenn der Debugger an den Kernel angehängt ist, tritt der Fehler deutlich seltener auf und es lässt sich meist problemlos laden. Wenn er auftritt, meckert VS, dass mindestens 2 Threads des Kernels in einem Deadlock sind. Im Anhang sind Screenshots der entsprechenden Codezeilen, an denen die beiden Threads hängen. Zumindest bei diesem Test waren die Parameter der Scenelist “Nebel” (GUID: “c2ccd931-75bc-4740-a6b5-59f3736e5399”) die, welche nicht korrekt übertragen wurden. Wobei ich bisher noch nicht weiß, ob das nur Zufall ist, oder ob diese Scenelist tatsächlich ein Problem hat.
14.08.2024 20:48
Reason for closing: Repariert
Additional comments about closing:
Bitte in RC4 testen
Ich hab die Collections mal gegen nicht blockierende Varianten getauscht. Das hab ich an anderen Stellen auch gemacht. Kannst du nochmal versuchen das zu reproduzieren? Auf meinem Laptop ging das nicht, der ist vermutlich zu langsam bzw. hat zu wenig Kerne ich bin nicht in den Deadlock gelaufen, daher hab ich das jetzt mal Blind korrigiert.
So, Rückmeldung des Users war, dass dieses Problem mit diesen Änderungen weg ist. Das ganze kann also im nächsten RC getestet werden.