Many thanks for following up on this. We believe we’ve solved the most serious of memory leaks here (thanks again for your great reporting on that which helped us find numerous issues).
However, I am able to reproduce your reported behavior in OpenGL Driver Monitor, despite the fact that we have matched pairs of glGenTextures and glDeleteTextures, and we consistently reuse the same texture ids. The OpenGL driver monitor reports them growing however, which is curious, and suggests that it marks them for "garbage collection" or similar at a later point.
On a lark, I tried deleting the context and rebuilding it, and it would seem seem from using OpenGL monitor that in such a case, it reclaims these textures. I’m not sure of a better way to trigger this reclamation at this point and I didn’t let run long enough to confirm whether or not it solves the crashes, but please try sending the jit.window object the message "depthbuffer 0, depthbuffer 1" to reclaim these textures, and let us know what you find.