GLContextShareSet leaks GLContexts (?)

Hello,

We came across what looks like a potential leak of GLContexts in the class jogamp.opengl.GLContextShareSet.

Whenever we create a context that is linked to a master context we have here is what happen:
-> GLContextShareSet#addNew
--> Adds the new context in destroyedShares Map
-> GLContextShareSet#contextCreated
--> Removes the new context from destroyedShares Map
--> Adds the new context to createdShares Map

Then when we close the corresponding window it tries to destroy the context
-> GLContextShareSet#contextDestroyed
--> Removes the context from createdShares Map
--> Adds the context to destroyedShares Map

So at the end of the day, the context is still referenced by the destroyedShares Map.

And it gets stranger when I look at the code, as there is no way to actually remove a context from destroyedShares Map. The only place where #remove() is called on destroyedShares is in contextCreated, which adds the context to the createdShares Map.

Hi

It reminds me a known problem. Which version of JOGL do you use? I'm almost sure that someone had the same problem and suggested a patch.

https://github.com/sgothel/jogl/pull/101
https://jogamp.org/bugzilla/show_bug.cgi?id=1312#c2

Thanks, we'll try that and see if it solves the issue.

Do you plan to merge this fix in a specific version/build ?

We'd like to release a maintenance version but there is no real plan yet.

I will provide a more simple fix if and only if I find one, otherwise I'll merge this one mostly as is.

Ok thanks, fyi here is the full context:

Our users use virtualized workstations, so each physical workstation is shared by many users.
The actual problem we encountered is that, after a while, the XServer returns an error when we try to create a new context.
Running the following command:
/usr/sbin/lsof -U | grep socket | grep java | wc -l

Has shown that everytime we open and close a window using a GL context the XSocket is not closed/released (value returned by the command above is increasing).
For some reasons it happens only on those virtual workstation, on a real one, the socket is actually closed.
Our assumption/hypothesis is that a proper local XServer is more aggressive and release the resources/native-context even if it's still referenced by the java application.

As many users use the same XServer, the limit is "quickly" reached.

If you're really in a hurry, just build JOGL yourself with the patch above. We can assist you if you need some help. There are some detailed instructions in the wiki.