octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53733] Panic/segfault when calling Java metho


From: Adrian
Subject: [Octave-bug-tracker] [bug #53733] Panic/segfault when calling Java method after forge:im[read|write]
Date: Mon, 23 Apr 2018 18:38:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

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

                 Summary: Panic/segfault when calling Java method after
forge:im[read|write]
                 Project: GNU Octave
            Submitted by: adaerr
            Submitted on: Mon 23 Apr 2018 10:38:07 PM UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Segfault, Bus Error, etc.
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.2.2
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Panic/segfault when calling Java method after forge:im[read|write]

The following minimal (non-)working example causes octave to
reproducibly panic and abort on two out of four (fairly up-to-date
Debian testing) GNU/Linux boxes I tested, and to freeze on a third
Computer.

Note that there is no error when either the "imwrite" instruction or
the last line is commented.


javaaddpath(".")
pkg load image

imwrite(zeros(1000), "foo.png");

graph = javaObject("Baz");
graph.addNodes(1:1000000);


An additional file "Baz.java" with the content


public final class Baz {
    public int addNodes(int[] nodes) {
        return 42;
    }
}


needs to be compiled ("javac Baz.java") and the class file put in
octave's working directory. A pre-compiled class file for java >= 8 is
attached. Then the code at the top of this message is either pasted
into the command window of an octave GUI, or stored in a file
crashtest.m in the same directory as Baz.class and the run via "rm -f
octave-workspace; octave --no-gui crashtest.m". When run in a terminal
this way, I see this error message on two of four computers:


panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
warning: called from
    crashtest.m at line 7 column 1
save to 'octave-workspace' complete
zsh: segmentation fault  octave --no-gui crashtest.octave


When pasted into a GUI, the message shown after the crash in the
terminal used to launch octave, is "octave exited with signal 11".

On a third Linux box both the command-line and the GUI do not crash
but start hogging a CPU (becoming unresponsive, including to Ctrl-C)
until manually terminated.

No idea for the moment why one out of A fourth Computers I tested is
immune to this bug in GUI mode: it executes the code and shows a
prompt, as expected. In text-mode octave does panic, but with a
slightly different message


panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
save to 'octave-workspace' complete
zsh: abort      octave --no-gui crashtest.octave

).

Can anybody reproduce this ? I have no clue for the moment why the
behaviour differs among the tested machines. 

Here's the list of octave-related packages installed on one of the two
segfaulting systems. For Java I tried openjdk versions 8 and 9 with
the same result.


$> dpkg -l octave'*'
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  octave         4.2.2-2      amd64        GNU Octave language for
numerical
ii  octave-common  4.2.2-2      all          architecture-independent files
fo
ii  octave-control 3.1.0-2      amd64        computer-aided control system
des
ii  octave-doc     4.2.2-2      all          documentation of the GNU Octave
l
ii  octave-geometr 3.0.0-6      amd64        geometric computing functions
for
un  octave-htmldoc <none>       <none>       (no description available)
ii  octave-image   2.6.2-5      amd64        image manipulation for Octave
un  octave-info    <none>       <none>       (no description available)
ii  octave-io      2.4.10-3     amd64        input/output data functions for
O
ii  octave-optim   1.5.2-4      amd64        unconstrained non-linear
optimiza
ii  octave-signal  1.3.2-5      amd64        signal processing functions for
O
ii  octave-struct  1.0.14-3     amd64        additional structure
manipulation

$> uname -a
Linux rouge 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64
GNU/Linux


p.s.
Despite the dependency of my example on the octave-forge 'image'
package I deliberately omit the '[octave-forge]' in the title because
the interaction with the java handling code, and the type of error,
seem to indicate some more general problem with memory corruption.
Feel free to add it back if it seems appropriate.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 23 Apr 2018 10:38:07 PM UTC  Name: crashtest.m  Size: 121B   By:
adaerr

<http://savannah.gnu.org/bugs/download.php?file_id=44000>
-------------------------------------------------------
Date: Mon 23 Apr 2018 10:38:07 PM UTC  Name: Baz.java  Size: 91B   By: adaerr

<http://savannah.gnu.org/bugs/download.php?file_id=44001>
-------------------------------------------------------
Date: Mon 23 Apr 2018 10:38:07 PM UTC  Name: Baz.class  Size: 240B   By:
adaerr

<http://savannah.gnu.org/bugs/download.php?file_id=44002>

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]