[Octave-bug-tracker] [bug #53733] Panic/segfault when calling Java method after forge:im[read|write]

[Adrian]

Follow-up Comment #65, bug #53733 (project octave):

Another observation: If you call imformats() *before* javaaddpath("."), then
you have the same behaviour as when you don't call it at all (comment #63).
Could it be that both the jvm and graphicsmagick change signal handling in
such a way that it affects the other ? Is signal handling global, i.e. shared
between these parts and octave ? So if graphicsmagick initialises before the
jvm is created, the JVM's SIGSEGV-trickery works fine, but otherwise
graphicsmagick's initialisation code modifies signal handlers in such a way
that the signal that the JVM was supposed to catch and handle internally for
its stack banging escapes the JVM and kills octave ?

In accordance with the idea that the order of _initialisation_ matters, if
imformats() is called before javaaddpath("."), then it may be called again
afterwards without reducing the argument size producing a fatal segfault. That
is both


fmt = imformats ();
javaaddpath (".")
fmt = imformats ();
graph = javaObject ("Baz");
for k=1:10
  N=10^k
  graph.addNodes (1:N);
endfor


and 


javaaddpath (".")
graph = javaObject ("Baz");
for k=1:10
  N=10^k
  graph.addNodes (1:N);
endfor


go up to N=1e9 before crashing octave with a segfault (as discussed in comment
#63, a continuable segfault is caught by gdb for N=1e5, and is not affecting
the test script when running outside gdb).


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/