Platform:
- Windows 11
- Python 3.8
- pySSV 0.6.2
- GTX 1660 Ti
To Reproduce:
When running the "Multi-Pass Rendering" demo from introduction.ipynb, the render process crashes while rendering the first frame. Unfortunately it crashes sufficiently violently that no error message ever gets logged.
Analysis:
The particular line that seems to be causing the crash is:
vb.update_vertex_buffer(np.array([...
This is strange because after tracing the issue the crash occurs inside ssv_render_opengl.SSVRenderOpenGL.read_frame(), specifically the error is a null-dereference deep inside of nvoglv64.dll
Interestingly as well, is that the "Camera" demo just below in the notebook calls the same update_vertex_buffer method with the same parameters (albeit on the main renderbuffer and not a custom one) and doesn't crash.
I've had a look through git blame and can't seem to find anything that's changed around that part of the code since Dec-2023, and AFAIK the code worked then. This issue might be hard to reproduce. To debug it, so far what I've done is put a time.sleep(10) just before the frame_buffer.read(...) call such that I can attach WinDbg to the render process during this sleep and record the process for Time Travel debugging; I haven't got very far with finding the root cause yet. (note to self: the recording is in your Documents/python01.run).
Other ideas: use RenderDoc with API validation to see if there's a dodgy call somewhere? Figure out if there's a way to enable the debug layer (in DX this is fairly straightforward and gives good insight, but idk about OpenGL). It wouldn't surprise me if the root cause was due to a use-after-free (maybe the gc was too ambitious?); or maybe the texture is being locked/used by something else and isn't available?
Platform:
To Reproduce:
When running the "Multi-Pass Rendering" demo from introduction.ipynb, the render process crashes while rendering the first frame. Unfortunately it crashes sufficiently violently that no error message ever gets logged.
Analysis:
The particular line that seems to be causing the crash is:
This is strange because after tracing the issue the crash occurs inside
ssv_render_opengl.SSVRenderOpenGL.read_frame(), specifically the error is a null-dereference deep inside of nvoglv64.dllInterestingly as well, is that the "Camera" demo just below in the notebook calls the same
update_vertex_buffermethod with the same parameters (albeit on the main renderbuffer and not a custom one) and doesn't crash.I've had a look through git blame and can't seem to find anything that's changed around that part of the code since Dec-2023, and AFAIK the code worked then. This issue might be hard to reproduce. To debug it, so far what I've done is put a
time.sleep(10)just before theframe_buffer.read(...)call such that I can attach WinDbg to the render process during this sleep and record the process for Time Travel debugging; I haven't got very far with finding the root cause yet. (note to self: the recording is in your Documents/python01.run).Other ideas: use RenderDoc with API validation to see if there's a dodgy call somewhere? Figure out if there's a way to enable the debug layer (in DX this is fairly straightforward and gives good insight, but idk about OpenGL). It wouldn't surprise me if the root cause was due to a use-after-free (maybe the gc was too ambitious?); or maybe the texture is being locked/used by something else and isn't available?