Memory leak when using jscip.MessageHandler

[patrickguenther]

It's not a large leak but could become a nuisance for long running applications that solve many optimization problems.

The leak was discovered by accident, while debugging an entirely different issue. The attached screenshot shows a heap dump of our application created by visualvm.

The number of retained ScipMessageHandler instances only goes up while running more optimization problems and never down even after explicitly invoking garbage collection.

The generated code for jscip.MessageHandler has a close method with an empty body defined. I guess the expected behavior would be that it frees _messagehdlrptr somehow? Or do I need to call some other JSCIP method to free it?

In the meantime, workarounds are:

• ignore the problem as the leak is not that large
• don't use message handlers

[kkofler]

Something somewhere needs to be deleted indeed, but I do not think close() is the right place. (Note also that jscip.MessageHandler is not generated, it is a wrapper around the generated ObjMessagehdlr and SWIGTYPE_p_SCIP_Messagehdlr classes.)

Try adding this to the anonymous ObjMessagehdlr subclass in MessageHandler.java (i.e., before line 41):

        @Override
        public synchronized void delete() {
          super.delete();
          swigTakeOwnership();
        }

That should clear the reference to the ObjMessageHdlr subclass instance created by the objmessagehdlr.swigReleaseOwnership(); in line 42 when the underlying C++ object is deleted (because, through C++ virtual destructors, that ends up calling ObjMessageHdlr.swigDirectorDisconnect via JNI, which then calls ObjMessageHdlr.delete). So then the nested class should be possible to garbage-collect, which in turn clears the reference to the containing MessageHandler class and should allow that, too, to be garbage-collected.