GH: unexpected Rhino crash.
See original GitHub issueNot sure if this is speckle related or not. I had 3 GH definitions opened and I was moving around between them. Then jumping from one definition to anther one, suddenly rhino just crush.
[ERROR] FATAL UNHANDLED EXCEPTION: System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.WebSockets.InternalClientWebSocket'.
at System.Net.WebSockets.WebSocketBase.ThrowIfDisposed()
at System.Net.WebSockets.WebSocketBase.WebSocketOperation.<Process>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Net.WebSockets.WebSocketBase.<SendAsyncCore>d__47.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at GraphQL.Client.Http.Websocket.GraphQLHttpWebSocket.<SendWebSocketMessageAsync>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at GraphQL.Client.Http.Websocket.GraphQLHttpWebSocket.<SendWebSocketRequestAsync>d__30.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at GraphQL.Client.Http.Websocket.GraphQLHttpWebSocket.<>c__DisplayClass27_1`1.<<CreateSubscriptionStream>b__7>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
[END ERROR]
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Rhino crashing on save after loading my .gh file, please help!
Hello, Everything was working correctly, but then all of a sudden my rhino file crashes. After I open my .gh file, I save...
Read more >Saving Grasshopper file when rhino crashes
I have checked the GH file and its 1mb when all data is internalized. I hope its not that big file. It is...
Read more >Gh file built using Rhino 6 crashes when opening in Rhino 7
When I try to open these in using v7 both Grasshopper and Rhino crash with no error message shown. These models were built...
Read more >Release Notes - SOFiSTiK Rhinoceros Interface 2023
If you detect any issue or unexpected behaviour please contact the SOFiSTiK ... Fixed crash when opening Rhino/GH Interface within Rhino.Inside for Revit ......
Read more >gHowl | Food4Rhino
... crashes GH / Rhino). OSC Channel - This component allows the storage of a single OSC Channel. Change the component's nickname to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
From the stack trace, it looks like something thrown by the graphql client lib that we are using. We’ll investigate!
OH! thanks for this, it will be super useful! I’ll try to reproduce your steps and hopefully we can find the culprit of this nasty crash!
If the receiver is still “receiving” while you do the change, we may just need to listen to the proper event and cancel any operations that are on going. GH does not like things happening in “non-active” documents.