buttplug-csharp icon indicating copy to clipboard operation
buttplug-csharp copied to clipboard

Intermittent crashes - "An item with the same key has already been added. Key: 3"

Open sippeangelo opened this issue 4 years ago • 4 comments

I've been getting internal exceptions like these a lot, crashing my application for a lot of users. I'm not sure when this happens, but it does...

Also not sure if this is the correct place to report this, but it seems to be related to the internals of the C# lib. I am using the Unity version of it though, but I'm guessing that's the same code?

[Error] System.ArgumentException: An item with the same key has already been added. Key: 3

  at System.Collections.Generic.Dictionary`2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) [0x000c1] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (TKey key, TValue value) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at Buttplug.Client.ButtplugClient+<MessageReceivedHandler>d__41.MoveNext () [0x000af] in <eeafe8c3464a4d23b76ace3509ff08c3>:0 

--- End of stack trace from previous location where exception was thrown ---

  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_1 (System.Object state) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (System.Object state) [0x00007] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00071] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00021] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0

sippeangelo avatar Dec 06 '20 19:12 sippeangelo

Huh. Of course a new bug is going to crop up right before deprecation even though the library hasn't been touched in over a year. :|

Anyways, yeah, about to move to a completely new codebase, and Unity will be moving with that, so this is basically a WONTFIX until that happens (should be next couple of weeks). Not sure exactly how the system is getting the same message twice though.

qdot avatar Dec 06 '20 19:12 qdot

Here are some logs from intiface from a different computer that might be relevant! Initface_Crash_log_VRChat_running_JaceVibe_Mod_12_05_2020_544pm.txt

These lines look sus

2020-12-05T22:41:39.520Z : backend : m : Process Log: {"timestamp":"Dec 05 17:41:39.520","level":"INFO","fields":{"message":"Device map does not contain key!"},"target":"buttplug::server::device_manager"}
2020-12-05T22:41:39.522Z : backend : m : Process Log: {"timestamp":"Dec 05 17:41:39.520","level":"INFO","fields":{"message":"Assigning index 6 to WeVibe Verge"},"target":"buttplug::server::device_manager"}

Relevant exception

[Error] System.ArgumentException: An item with the same key has already been added. Key: 6

  at System.Collections.Generic.Dictionary`2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) [0x000c1] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (TKey key, TValue value) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at Buttplug.Client.ButtplugClient+<MessageReceivedHandler>d__41.MoveNext () [0x000af] in <ff8ae79bd29346a8a65de91db58fcea8>:0 

--- End of stack trace from previous location where exception was thrown ---

  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_1 (System.Object state) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (System.Object state) [0x00007] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00071] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00021] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <e1319b7195c343e79b385cd3aa43f5dc>:0 

sippeangelo avatar Dec 06 '20 19:12 sippeangelo

This looks a lot like a duplicate of #664 I've seen this a few times outside of Xamarin where I originally saw it when there's high command traffic and devices dropping in/out.

You might be able to reduce the likelihood of hitting the exception if you call StopScanning before you start sending commands.

blackspherefollower avatar Dec 07 '20 07:12 blackspherefollower

This looks a lot like a duplicate of #664 I've seen this a few times outside of Xamarin where I originally saw it when there's high command traffic and devices dropping in/out.

You might be able to reduce the likelihood of hitting the exception if you call StopScanning before you start sending commands.

Thanks for the tip! I'll try your patch and see if it helps!

sippeangelo avatar Dec 08 '20 05:12 sippeangelo

Merged hopeful fix for this, closing for now.

qdot avatar Dec 27 '22 21:12 qdot