textures fill the memory and crash

Oct 17, 2013 at 2:53pm

textures fill the memory and crash

Hi, I have a big problem for several months:

In a bpatcher i load and reload different patches whit inside a lot of jit.gl.slab and jit.gl.pix
after some hours my patch crash and i discovered by “Opengl driver monitor” that the texture number increase after each replacement in the subpatch
until the crash
here there is a patch you can reproduce the bug
and here two images to better understand the problem.

Can someone help me I’m on the new 6.1.4

Thanks

#268321
Oct 17, 2013 at 2:56pm

here the screenshots
see the textures red number in “OpenGL driver monitor”

Attachments:
  1. finish
  2. start
#268322
Oct 21, 2013 at 3:14pm

can someone reproduce this bug?

#268677
Oct 22, 2013 at 12:41pm

hi micron. where is the patch?

#268787
Oct 22, 2013 at 12:58pm

ops yes…
here is the patch

Attachments:
  1. CRASH.zip
#268790
Oct 23, 2013 at 4:42pm

Hi Micron,

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.

Thanks,
Joshua

#268949
Oct 31, 2013 at 11:44am

hi micron.
thanks again for the report.
we’ve managed to isolate this memory leak, and have fixed for the next update.

#269780
Oct 31, 2013 at 1:15pm

Thanks Joshua, your workaround works for my patch.
Thanks Rob for your support.

#269786

You must be logged in to reply to this topic.