[Octave-bug-tracker] [bug #47372] Memory leaks and segmentation faults in Octave

[Rik]

Follow-up Comment #84, bug #47372 (project octave):

I have taken a preliminary look at the memory leaks through the JNI interface
to Java.  First, the interface was coded long ago and doesn't necessarily
follow modern JNI practices.  Unless someone has a strong interest, or a
financial backer can be found, I think we have to make do with the code we
have.

At a minimum, however, I think we ought to be calling terminate_jvm (or use
atexit ("__java_exit__") so that we shut down the JVM as we are exiting
Octave.  This might prompt the JVM, for example, to write out any buffers to
disk, etc.  In any case, I tried the above and it doesn't help with the memory
leaks.

The memory leak size seems to be pretty static which is a good thing. 
Although it is about 170K on my machine, it doesn't seem to grow if I create
and clear javaObjects.  Thus, I don't think it is a threat to a long-running
Octave session.  There does seem to be slight growth as new classes are used. 
I suspect this is because some information is cached about each class in the
JNI interface.

Unless one of the conditions in paragraph 1 is true, I'm going to ignore Java
leaks.

Right now (4/5/16) the only remaining leak source to be addressed is the
classdef code.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47372>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/