IronPython stack trace following a Rhino crash

Rhino Developer
,
1

We’re developing a python framework which can be used via RhinoPython/Grasshopper. Occasionally, while testing new developments, Rhino abruptly crashes running the code. Working around these issues is mostly based on guesswork since the IronPython stack trace from running the code is lost.

Is said stack trace saved anywhere in the event of a crash? Is there anyway to get Rhino to save it?

Creating a contrived minimal example which would reproduce the issue often proves tricky due to inheritance trees and general complexity of the framework.

Additionally, I am not seeing any crash dump being created on the Desktop after the crash, is it possible that it is created somewhere else?

Below are the SystemInfo extract and the Windows EventViewer entry:

Thanks!
Chen

Rhino 7 SR20 2022-7-12 (Rhino 7, 7.20.22193.09001, Git hash:master @ 9b19bfdb8c343dd6fa8df3514068defd72273d6f)
License type: Educational Lab License, build 2022-07-12
License details: Cloud Zoo

Windows 10 (10.0.19044 SR0.0) or greater (Physical RAM: 32Gb)

Computer platform: LAPTOP  - Unplugged [72% battery remaining] ~344 minutes left

Standard graphics configuration.
  Primary display and OpenGL: Intel(R) Iris(R) Xe Graphics (Intel) Memory: 1GB, Driver date: 5-31-2022 (M-D-Y). OpenGL Ver: 4.6.0 - Build 31.0.101.1999
    > Integrated graphics device with 4 adapter port(s)
        - Secondary monitor is laptop's integrated screen or built-in port
        - Windows Main Display attached to adapter port #1

OpenGL Settings
  Safe mode: Off
  Use accelerated hardware modes: On
  Redraw scene when viewports are exposed: On
  Graphics level being used: OpenGL 4.6 (primary GPU's maximum)
  
  Anti-alias mode: 4x
  Mip Map Filtering: Linear
  Anisotropic Filtering Mode: High
  
  Vendor Name: Intel
  Render version: 4.6
  Shading Language: 4.60 - Build 31.0.101.1999
  Driver Date: 5-31-2022
  Driver Version: 31.0.101.1999
  Maximum Texture size: 16384 x 16384
  Z-Buffer depth: 24 bits
  Maximum Viewport size: 16384 x 16384
  Total Video Memory: 1 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
  C:\Program Files\Rhino 7\Plug-ins\Commands.rhp	"Commands"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\rdk.rhp	"Renderer Development Kit"	
  C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp	"Rhino Render"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp	"RDK_EtoUI"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp	"Renderer Development Kit UI"	
  C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp	"Snapshots"	
  C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp	"RhinoCycles"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\Grasshopper\GrasshopperPlugin.rhp	"Grasshopper"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp	"Toolbars"	7.20.22193.9001
  C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp	"3Dconnexion 3D Mouse"	
  C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp	"Displacement"

EventViewer entry: (faulting module seems to vary for the same instance of the error [sometimes ntdll.dll])

Faulting application name: Rhino.exe, version: 7.20.22193.9001, time stamp: 0x62cd9e22
Faulting module name: clr.dll, version: 4.8.4510.0, time stamp: 0x62461f56
Exception code: 0xc00000fd
Fault offset: 0x0000000000005303
Faulting process id: 0xae8
Faulting application start time: 0x01d8ae555e00c023
Faulting application path: C:\Program Files\Rhino 7\System\Rhino.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 7ca84980-d2d9-41e0-82a8-cb3da06e1b26
Faulting package full name: 
Faulting package-relative application ID:
2

If the exception is managed, you will see a RhinoDotNetCrash.txt on your desktop.

0xc00000fd is a stack overflow exception. Does your code involve infinite recursive calls?

But it seems the crash is in clr.dll which means something corrupted the managed state, probably from IronPython’s dynamic code generation, possibly resulting in an execution engine issue.

Personally I enable full user mode dump on my computer, and you will get a dump everytime Rhino crashes, which can be later analyzed by WinDbg. WinDbg would give you a full image of what’s going on.

3

Yes! The last issue had to do with deepcopy-ing an instance of a rather big class with some circular references, which I can imagine requires quite a deep recursion. Since this wasn’t an issue with CPython, I’m guessing CPython’s stack was simply bigger. Getting rid of some of the circular references before copying solved the problem.

Funny I never bothered looking up the error code in the event entry, felt there wasn’t much information there.

I will have a look at activating user-mode dump as you suggested, might be useful for the next time.

Thanks a lot!
Chen

Edit: Didn’t see this coming

Python 3.8.13 (default, Mar 28 2022, 06:59:08) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getrecursionlimit()
1000

IronPython 2.7.12 (2.7.12.1000)
[.NETFramework,Version=v4.5 on .NET Framework 4.8.4510.0 (64-bit)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getrecursionlimit()
2147483647
4

It’s because CPython’s recursion limit is lower so the stack-overflowing function terminates in the Python domain (much easier to debug because the actual system limit hasn’t been reached), rather than causing the .NET runtime to overflow (when system limit is reached so no extra resource can be used, even to produce a stacktrace).

Lastly it’s better to implement a BFS algorithm to copy objects, which can detect circular references and avoid too deep data structure.

1 Like