From 55cf06c68c5fff48841e077a220acda4fedb44fa Mon Sep 17 00:00:00 2001 From: Ivan Migalev Date: Sat, 19 Dec 2020 22:21:51 +0700 Subject: [PATCH] ByteBufferAsyncProcessor: prevent deadlocks on corrupted state exceptions It turns out that some of our code works under [HandleProcessCorruptedStateExceptions] attribute on .NET Framework. This attribute allows the process to proceed execution even in case of memory access violation, but will only execute catch and finally blocks in direct methods marked with the attribute. So, if ByteBufferAsyncProcessor.Put is called from such method, and then an exception occurs inside of the lock block, the lock will be abandoned in a locked state. This could lead to deadlocks that are hard to detect. Provided we don't want to change the behavior of all the external code right now, the safest action we could take is to guard the path leading to our logger with the same attribute. It will at least help to preserve the logger functionality even in case of corrupted state exception, which should be helpful. --- rd-net/Lifetimes/Threading/ByteBufferAsyncProcessor.cs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/rd-net/Lifetimes/Threading/ByteBufferAsyncProcessor.cs b/rd-net/Lifetimes/Threading/ByteBufferAsyncProcessor.cs index 312c4c524..0821646ed 100644 --- a/rd-net/Lifetimes/Threading/ByteBufferAsyncProcessor.cs +++ b/rd-net/Lifetimes/Threading/ByteBufferAsyncProcessor.cs @@ -463,6 +463,9 @@ [PublicAPI] public void Put(UnsafeWriter.Cookie data) } +#if !NET35 + [System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions] // to force myLock to be unlocked even in case of corrupted state exception +#endif [PublicAPI] public void Put(byte* start, int count) { if (count <= 0) return;