bugGNU Octave - Bugs: bug #53733, Panic/segfault when calling Java...

 
 

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

Submitter:  Adrian <adaerr>
Submitted:  Mon 23 Apr 2018 10:38:07 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 4.4.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 23 Dec 2018 10:04:20 PM UTC, comment #81: 

I had to kill -9 mine manually after about ~50 minutes running.
It was hanging at N = 1e9. If I run directly (w/o loop)
with N=1e10 I get:


octave:1> javaaddpath (".")
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "org.octave.OctClassLoader"). To use archived non-system classes, this property must be not be set
octave:2> fmt = imformats ();
octave:3> graph = javaObject ("Baz");
octave:4> graph.addNodes (1:1e10);
error: out of memory or dimension too large for Octave's index type
octave:4>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 23 Dec 2018 09:45:56 PM UTC, comment #80: 

When I use the script from comment #75, I also DO get a crash at N=10^9 with Octave 5.0.1 (hg-id 9644c0b7efd8). The call for imformats was included. It takes 2-3 minutes.

Sorry, so this issue seems to be still alive :(

Hartmut <hardy>
Sun 23 Dec 2018 09:39:50 PM UTC, comment #79: 

Less than a second before crashing at N=1e5 when I call imformats first. About 3-5 seconds to crash at N=1e9 when I don't call imformats.

Mike Miller <mtmiller>
Group Member
Sun 23 Dec 2018 08:58:35 PM UTC, comment #78: 

OK. This is better. How long does it take before it crashes?
Mine is sitting at N=10^9 for about 10 minutes already with 100% cpu load and 16GB virt and 8GB res memory in use...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 23 Dec 2018 08:43:30 PM UTC, comment #77: 

Dmitri - you need to download and compile the Baz.java attachment.

Mike Miller <mtmiller>
Group Member
Sun 23 Dec 2018 08:28:25 PM UTC, comment #76: 

This is what i got:


octave:1> javaaddpath (".")
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "org.octave.OctClassLoader"). To use archived non-system classes, this property must be not be set
octave:2> fmt = imformats ();
octave:3> graph = javaObject ("Baz");
error: [java] java.lang.ClassNotFoundException: Baz
octave:3> for k=1:10

>   N=10^k
>   graph.addNodes (1:N);
> endfor

N =  10
warning: the 'graph' function is not yet implemented in Octave

Please read <https://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
error: 'graph' undefined near line 3 column 3
octave:3>


This is with java-11

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 23 Dec 2018 08:15:27 PM UTC, comment #75: 

Please try the code example from comment #59:


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


This still crashes Octave 5.0.1 (d00577d95369) with a segmentation fault for me.

With the call to imformats, it crashes for me at N = 10^5. If the imformats line is removed, it crashes for me at N = 10^9.

Mike Miller <mtmiller>
Group Member
Sun 23 Dec 2018 07:42:47 PM UTC, comment #74: 

I followed the procedure outlined in comment #0 and could NOT generate any crash of a self-compiled Octave 5.0.1 (hg-id 9644c0b7efd8) on Ubuntu 18.04 with an image-2.10 pre-release package. (Sorry, I haven't read the 72 comments inbetween...)

Can anyone confirm, that this bug is GONE in Octave 5.0.1? (Without anyone intentionally solving it...)

Hartmut <hardy>
Thu 24 May 2018 10:12:50 PM UTC, comment #73: 

Another observation: graphicsmagick plays quite nicely when it comes
to signal handling: it refrains from installing its own handler when
one is already installed. Or to be precise: because there is no
function to simply inquire about the existing handler, graphicsmagick
installs its own signal handler, checks whether there was a
non-default handler installed, and restores the old handler if there
was one. See the source at:

http://hg.code.sf.net/p/graphicsmagick/code/file/356b0eba718c/magick/magick.c#l633

In any case, gdb confirms that the initialisation of
ImageMagick does not modify the signal handler for SIGSEGV:


1) at octave start-up:
11      SIGSEGV         Segmentation fault              octave::deadly_sig_handler(int) in section .text of /home/adrian/Programmes/slurp/octave-2cf750f5cb7d/libinterp/.libs/liboctinterp.so.5
2) after executing 'javaaddpath (".");':
11      SIGSEGV         Segmentation fault              signalHandler(int, siginfo_t*, void*) in section .text of /usr/lib/jvm/java-10-openjdk-amd64/lib/server/libjvm.so
3) after executing 'fmt = imformats ();'
11      SIGSEGV         Segmentation fault              signalHandler(int, siginfo_t*, void*) in section .text of /usr/lib/jvm/java-10-openjdk-amd64/lib/server/libjvm.so


Does this mean that the SEGV signal handling is not the culprit in
this bug, despite java's shenanigans in throwing that signal for an
argument size of 10^5 elements (about equal to the stack size) ?

The series of instructions


javaaddpath (".")
fmt = imformats ();
graph = javaObject ("Baz");
graph.addNodes (1:1e4);
graph.addNodes (1:1e5);


produces a SIGSEGV at the last line, but executes fine if the second
line is omitted. The table of signal handlers however is exactly the
same in both cases (whether ImageMagick is initialised or not).

A detailled debugging session follows for the script above.


$> gdb -ex 'handle SIGSEGV nostop print pass' -ex 'source Programmes/pas_de_moi/signals.gdb' --pid=${$(ps -C octave-gui -o pid=)// /}
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 14903
[New LWP 15031]
[New LWP 15032]
[New LWP 15033]
[New LWP 15034]
[New LWP 15035]
[New LWP 15036]
[New LWP 15037]
[New LWP 15038]
[New LWP 15039]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fa4b33115d9 in __GI___poll (fds=0x55666b64fee0, nfds=4, timeout=15817)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        Yes     Yes             Segmentation fault
(gdb) info signal-dispositions 11
Number  Name            Description                     Disposition
11      SIGSEGV         Segmentation fault              octave::deadly_sig_handler(int) in section .text of /home/adrian/Programmes/slurp/octave-2cf750f5cb7d/libinterp/.libs/liboctinterp.so.5
(gdb) break __GI___poll
Breakpoint 1 at 0x7fa4b3311590: file ../sysdeps/unix/sysv/linux/poll.c, line 29.
(gdb) cont
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
###########################
## octave-gui executing 'javaaddpath (".")' here
###########################

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[New Thread 0x7fa459831700 (LWP 15046)]
[New Thread 0x7fa45972f700 (LWP 15047)]
[New Thread 0x7fa45962d700 (LWP 15048)]
[New Thread 0x7fa45952b700 (LWP 15049)]
[New Thread 0x7fa44b73a700 (LWP 15050)]
[New Thread 0x7fa44b638700 (LWP 15051)]
[New Thread 0x7fa449132700 (LWP 15052)]
[New Thread 0x7fa449030700 (LWP 15053)]
[New Thread 0x7fa448f2e700 (LWP 15054)]
[New Thread 0x7fa448e2c700 (LWP 15055)]
[New Thread 0x7fa448d2a700 (LWP 15056)]
[New Thread 0x7fa4483b2700 (LWP 15057)]
[New Thread 0x7fa4482b0700 (LWP 15058)]
[New Thread 0x7fa4481af700 (LWP 15059)]
[New Thread 0x7fa43c34f700 (LWP 15060)]
[New Thread 0x7fa43c24e700 (LWP 15061)]
[New Thread 0x7fa43c14d700 (LWP 15062)]
[New Thread 0x7fa407fff700 (LWP 15063)]
[New Thread 0x7fa407efe700 (LWP 15064)]
[New Thread 0x7fa407dfd700 (LWP 15065)]
[New Thread 0x7fa4078d2700 (LWP 15066)]
[New Thread 0x7fa4077d1700 (LWP 15067)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) info signal-dispositions 11
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
The program stopped in another thread while making a function call from GDB.
Evaluation of the expression containing the function
(malloc) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) cont
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]
(gdb) info signal-dispositions 11
Number  Name            Description                     Disposition
11      SIGSEGV         Segmentation fault              signalHandler(int, siginfo_t*, void*) in section .text of /usr/lib/jvm/java-10-openjdk-amd64/lib/server/libjvm.so
(gdb) cont
Continuing.

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
###########################
## octave-gui executing 'fmt = imformats ();' here
###########################
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a638998,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) info signal-dispositions 11
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
The program stopped in another thread while making a function call from GDB.
Evaluation of the expression containing the function
(malloc) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) cont
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]
(gdb) info signal-dispositions 11
Number  [Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
The program stopped in another thread while making a function call from GDB.
Evaluation of the expression containing the function
(malloc) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) cont
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]
(gdb) info signal-dispositions 11
Number  Name            Description                     Disposition
11      SIGSEGV         Segmentation fault              signalHandler(int, siginfo_t*, void*) in section .text of /usr/lib/jvm/java-10-openjdk-amd64/lib/server/libjvm.so
(gdb)  cont
###########################
## octave-gui executing remaining instructions from here
###########################
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389b8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389d8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389f8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb) cont
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389a8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389c8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389a8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389c8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389a8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a6389c8,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a638938,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a638958,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x7ffc1a638d08,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb)
Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
cont
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb)
Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c

Continuing.
[Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.
[Switching to Thread 0x7fa4b7452940 (LWP 14903)]

Thread 1 "octave-gui" hit Breakpoint 1, __GI___poll (fds=0x55666b64fee0,
    nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
(gdb)
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

---Type <return> to continue, or q <return> to quit---q
Quit
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) cont
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) cont
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) cont
Continuing.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) [Switching to Thread 0x7fa49076d700 (LWP 15034)]

Thread 5 "QXcbEventReader" hit Breakpoint 1, __GI___poll (fds=0x7fa490765b68,
    nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c


BTW, if someone has a nicer way (than setting a breakpoint on __GI___poll as above) of returning to gdb after octave finishes executing one instruction and returns to the prompt, I'd be happy to learn.

Adrian <adaerr>
Thu 24 May 2018 09:01:39 PM UTC, comment #72: 

TLDR; Compiling with AddressSanitizer prevents premature SEGV stop.

I built the same source (current tip a few days ago: hg_id = 2cf750f5cb7d) with java-10 once with AdressSanitizer options:


octave:1> __octave_config_info__ ("hg_id")
ans = 2cf750f5cb7d
octave:2> __octave_config_info__ ("config_opts")
ans =  'FFLAGS=-g' 'CFLAGS=-g' 'CXXFLAGS=-g' '--enable-address-sanitizer-flags' '--prefix=/home/adrian/.local/dbg-octave' 'JAVA_HOME=/usr/lib/jvm/java-10-openjdk-amd64/'


and once without:


octave:2> __octave_config_info__ ("config_opts")
ans =  'FFLAGS=-g' 'CFLAGS=-g' 'CXXFLAGS=-g' '--prefix=/home/adrian/.local/octave-2cf750f5cb7d' 'JAVA_HOME=/usr/lib/jvm/java-10-openjdk-amd64/'


Then the following test script is executed on both builds:


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


The non-ASan version stops through a SEGV at k=5, while the build linked with ASan runs up to k=9 before stopping through a SEGV. No leak is reported.

Here's the output. Note the ASAN option to exclude SEGV signal handling by that tool.


$> ASAN_OPTIONS="leak_check_at_exit=0:verbosity=1:handle_segv=0" ./run-octave --norc --silent --no-history --no-gui testscript.m
==9435==AddressSanitizer: failed to intercept '__isoc99_printf'
==9435==AddressSanitizer: failed to intercept '__isoc99_sprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_snprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_fprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
==9435==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==9435==Installed the sigaction for signal 8
==9435==T0: stack [0x7ffd39a71000,0x7ffd3a271000) size 0x800000; local=0x7ffd3a26d6ac
==9435==LeakSanitizer: Dynamic linker not found. TLS will not be handled correctly.
==9435==AddressSanitizer Init done
==9435==AddressSanitizer: failed to intercept '__isoc99_printf'
==9435==AddressSanitizer: failed to intercept '__isoc99_sprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_snprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_fprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
==9435==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
==9435==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==9435==Installed the sigaction for signal 8
==9435==T0: stack [0x7ffd44d58000,0x7ffd45558000) size 0x800000; local=0x7ffd45552fdc
==9435==LeakSanitizer: Dynamic linker not found. TLS will not be handled correctly.
==9435==AddressSanitizer Init done
==9435==T1: stack [0x7f3f4c200000,0x7f3f4c9f7d80) size 0x7f7d80; local=0x7f3f4c9f7c8c
==9435==T2: stack [0x7f3f4b9ff000,0x7f3f4c1f6d80) size 0x7f7d80; local=0x7f3f4c1f6c8c
==9435==T3: stack [0x7f3f491fe000,0x7f3f499f5d80) size 0x7f7d80; local=0x7f3f499f5c8c
==9435==poisoning: 0x7ffd45552680 400
==9435==unpoisoning: 0x7ffd45552d40 210
==9435==T4: stack [0x7f3f40c72000,0x7f3f41469d80) size 0x7f7d80; local=0x7f3f41469c8c
==9435==T5: stack [0x7f3f3aa65000,0x7f3f3b25cd80) size 0x7f7d80; local=0x7f3f3b25cc8c
==9435==T6: stack [0x7f3f3a264000,0x7f3f3aa5bd80) size 0x7f7d80; local=0x7f3f3aa5bc8c
==9435==unpoisoning: 0x7ffd45552970 2b8
==9435==T7: stack [0x7f3f39a63000,0x7f3f3a25ad80) size 0x7f7d80; local=0x7f3f3a25ac8c
==9435==T8: stack [0x7f3f39262000,0x7f3f39a59d80) size 0x7f7d80; local=0x7f3f39a59c8c
==9435==T9: stack [0x7f3f38a61000,0x7f3f39258d80) size 0x7f7d80; local=0x7f3f39258c8c
==9435==unpoisoning: 0x7f3f3a25a340 178
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a2542a0 140
==9435==unpoisoning: 0x7f3f3a24f140 178
==9435==poisoning: 0x7f3f3a24f140 178
==9435==poisoning: 0x7f3f3a250980 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a245750 140
==9435==poisoning: 0x7f3f3a251a50 140
==9435==unpoisoning: 0x7f3f3a24bb20 178
==9435==poisoning: 0x7f3f3a24bb20 178
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==unpoisoning: 0x7f3f3a24ba20 178
==9435==poisoning: 0x7f3f3a24ba20 178
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a24d260 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a258950 140
==9435==poisoning: 0x7f3f3a254820 140
==9435==poisoning: 0x7f3f3a252370 758
==9435==unpoisoning: 0x7f3f3a252af0 14f0
==9435==poisoning: 0x7f3f3a252af0 14f0
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==unpoisoning: 0x7f3f3a255740 110
==9435==poisoning: 0x7f3f3a255740 110
==9435==unpoisoning: 0x7f3f3a255880 110
==9435==poisoning: 0x7f3f3a255880 110
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a255740 110
==9435==unpoisoning: 0x7f3f3a255880 110
==9435==poisoning: 0x7f3f3a255880 110
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a255880 110
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==unpoisoning: 0x7f3f3a255600 110
==9435==poisoning: 0x7f3f3a255600 110
==9435==unpoisoning: 0x7f3f3a255740 110
==9435==poisoning: 0x7f3f3a255740 110
==9435==unpoisoning: 0x7f3f3a255880 110
==9435==poisoning: 0x7f3f3a255880 110
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==unpoisoning: 0x7f3f3a255600 110
==9435==poisoning: 0x7f3f3a255600 110
==9435==unpoisoning: 0x7f3f3a255740 110
==9435==poisoning: 0x7f3f3a255740 110
==9435==unpoisoning: 0x7f3f3a255880 110
==9435==poisoning: 0x7f3f3a255880 110
==9435==unpoisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a2559c0 110
==9435==poisoning: 0x7f3f3a254490 140
==9435==unpoisoning: 0x7f3f3a259750 148
==9435==poisoning: 0x7f3f3a259750 148
==9435==unpoisoning: 0x7f3f3a257ae0 178
==9435==poisoning: 0x7f3f3a257ae0 178
==9435==poisoning: 0x7f3f3a2591f0 140
==9435==poisoning: 0x7f3f3a255a60 140
==9435==T10: stack [0x7f3f1e18e000,0x7f3f1e286d80) size 0xf8d80; local=0x7f3f1e286c8c
==9435==T11: stack [0x7f3f1e076000,0x7f3f1e16ed80) size 0xf8d80; local=0x7f3f1e16ec8c
==9435==T12: stack [0x7f3f1df5e000,0x7f3f1e056d80) size 0xf8d80; local=0x7f3f1e056c8c
==9435==T13: stack [0x7f3f1de46000,0x7f3f1df3ed80) size 0xf8d80; local=0x7f3f1df3ec8c
==9435==T14: stack [0x7f3e1ab6d000,0x7f3e1ac65d80) size 0xf8d80; local=0x7f3e1ac65c8c
==9435==T15: stack [0x7f3e1aa6b000,0x7f3e1ab63d80) size 0xf8d80; local=0x7f3e1ab63c8c
==9435==T16: stack [0x7f3e18559000,0x7f3e18651d80) size 0xf8d80; local=0x7f3e18651c8c
==9435==T17: stack [0x7f3e18441000,0x7f3e18539d80) size 0xf8d80; local=0x7f3e18539c8c
==9435==T18: stack [0x7f3e18329000,0x7f3e18421d80) size 0xf8d80; local=0x7f3e18421c8c
==9435==T19: stack [0x7f3e18211000,0x7f3e18309d80) size 0xf8d80; local=0x7f3e18309c8c
==9435==T20: stack [0x7f3e180f9000,0x7f3e181f1d80) size 0xf8d80; local=0x7f3e181f1c8c
==9435==T21: stack [0x7f3dd76b2000,0x7f3dd77aad80) size 0xf8d80; local=0x7f3dd77aac8c
==9435==T22: stack [0x7f3dd758a000,0x7f3dd7682d80) size 0xf8d80; local=0x7f3dd7682c8c
==9435==T23: stack [0x7f3dd7463000,0x7f3dd755bd80) size 0xf8d80; local=0x7f3dd755bc8c
==9435==T24: stack [0x7f3dd732c000,0x7f3dd7424d80) size 0xf8d80; local=0x7f3dd7424c8c
==9435==T25: stack [0x7f3dd7215000,0x7f3dd730dd80) size 0xf8d80; local=0x7f3dd730dc8c
==9435==T26: stack [0x7f3dd70fe000,0x7f3dd71f6d80) size 0xf8d80; local=0x7f3dd71f6c8c
==9435==T27: stack [0x7f3dd6fe6000,0x7f3dd70ded80) size 0xf8d80; local=0x7f3dd70dec8c
==9435==T28: stack [0x7f3dd6ece000,0x7f3dd6fc6d80) size 0xf8d80; local=0x7f3dd6fc6c8c
==9435==T29: stack [0x7f3dd6d56000,0x7f3dd6e4ed80) size 0xf8d80; local=0x7f3dd6e4ec8c
==9435==T30: stack [0x7f3dd6792000,0x7f3dd688ad80) size 0xf8d80; local=0x7f3dd688ac8c
==9435==T31: stack [0x7f3dd667a000,0x7f3dd6772d80) size 0xf8d80; local=0x7f3dd6772c8c
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==unpoisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a253a50 178
==9435==poisoning: 0x7f3f3a255290 140
==9435==poisoning: 0x7f3f3a24fe90 140
==9435==poisoning: 0x7f3f3a2506b0 140
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e780 178
==9435==poisoning: 0x7f3f3a24e780 178
==9435==poisoning: 0x7f3f3a24fe90 140
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e750 178
==9435==poisoning: 0x7f3f3a24e750 178
==9435==unpoisoning: 0x7f3f3a24e750 178
==9435==poisoning: 0x7f3f3a24e750 178
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e650 178
==9435==poisoning: 0x7f3f3a24e650 178
==9435==unpoisoning: 0x7f3f3a24e750 178
==9435==poisoning: 0x7f3f3a24e750 178
==9435==poisoning: 0x7f3f3a24fe90 140
k =  1
k =  2
k =  3
k =  4
k =  5
k =  6
k =  7
k =  8
k =  9
fatal: caught signal Segmentation fault -- stopping myself...
zsh: segmentation fault  ASAN_OPTIONS="leak_check_at_exit=0:verbosity=1:handle_segv=0" ./run-octave


Adrian <adaerr>
Mon 07 May 2018 03:18:50 PM UTC, comment #71: 

TLDR; In essence java 10 behaves as java 9 with respect to SIGSEGV
emission for the test script triggering bug at hand.

This was tested by downloading OpenJDK 64bit version "10.0.1"
2018-04-17 from java.net and compiling the current octave development
tip (af64921cdb28) against it. The machine has Intel Xeon E5520 CPUs
and is running Debian stable with kernel 4.9.0.



octave:4> __octave_config_info__ ("config_opts")
ans =  '--prefix=/home/adrian/.local' 'JAVA_HOME=/usr/lib/jvm/java-10-openjdk-amd64-javanet'
octave:5> __octave_config_info__ ("hg_id")
ans = af64921cdb28


There are minor differences to java 9, e.g. the critical argument size
in the method call that triggers a SIGSEGV signal is decreased from
1e6 (java-9) to 1e5 (java-10).

Here is the output:


$> rm -f octave-workspace; ../octave/run-octave --norc
GNU Octave, version 5.0.0
[..]
Octave was configured for "x86_64-pc-linux-gnu".
[..]
octave:1> javaaddpath (".")
octave:2> fmt = imformats ();
octave:3> graph = javaObject ("Baz");
octave:4> graph.addNodes(1:10);
octave:5> graph.addNodes(1:1e2);
octave:6> graph.addNodes(1:1e3);
octave:7> graph.addNodes(1:1e4);
octave:8> graph.addNodes(1:1e5);
fatal: caught signal Segmentation fault -- stopping myself...
zsh: segmentation fault  ../octave/run-octave --norc


Without the call to imformats, the addNodes(1:10^k) instructions
succeed for k=1..8, where octave takes several seconds to
complete the k=8 case. The segfault then occurs for an argument
size of 1e9, after somme calculation and swapping.

With gdb attached, and omitting the call to imformats, a SIGSEGV is
received for k=5, but can be ignored (either via "handle SIGSEGV
nostop print pass" in .gdbinit, or by typing "continue" at the gdb
prompt). Output follows (gdb is attached and the process execution
continued before pasting the test script lines at the octave prompt;
the 51 "New Thread" creations are in particular the result of the
instruction 'javaaddpath(".")'):


> gdb --pid=$(ps -C octave-gui -o pid=)
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
[..]
Attaching to process 11980
[New LWP 12106]
[New LWP 12107]
[New LWP 12108]
[New LWP 12109]
[New LWP 12110]
[New LWP 12111]
[New LWP 12112]
[New LWP 12113]
[New LWP 12114]
[New LWP 12115]
[New LWP 12116]
[New LWP 12117]
[New LWP 12118]
[New LWP 12119]
[New LWP 12120]
[New LWP 12121]
[New LWP 12122]
[New LWP 12123]
[New LWP 12124]
[New LWP 12125]
[New LWP 12126]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fb74918a5d9 in __GI___poll (fds=0x55863a95d8d0, nfds=4, timeout=15725)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) continue
Continuing.
[New Thread 0x7fb6f9449700 (LWP 12144)]
[New Thread 0x7fb6f9347700 (LWP 12145)]
[New Thread 0x7fb6f9245700 (LWP 12146)]
[New Thread 0x7fb6f9143700 (LWP 12147)]
[New Thread 0x7fb6f9041700 (LWP 12148)]
[New Thread 0x7fb6f8f3f700 (LWP 12149)]
[New Thread 0x7fb6f8e3d700 (LWP 12150)]
[New Thread 0x7fb6f8d3b700 (LWP 12151)]
[New Thread 0x7fb6f8c39700 (LWP 12152)]
[New Thread 0x7fb6f8b37700 (LWP 12153)]
[New Thread 0x7fb6f8a35700 (LWP 12154)]
[New Thread 0x7fb6f8933700 (LWP 12155)]
[New Thread 0x7fb6f8831700 (LWP 12156)]
[New Thread 0x7fb6ce5dd700 (LWP 12157)]
[New Thread 0x7fb6ce4db700 (LWP 12158)]
[New Thread 0x7fb6ce3d9700 (LWP 12159)]
[New Thread 0x7fb6ce2d7700 (LWP 12160)]
[New Thread 0x7fb69cce3700 (LWP 12161)]
[New Thread 0x7fb69cbe1700 (LWP 12162)]
[New Thread 0x7fb69cadf700 (LWP 12163)]
[New Thread 0x7fb69c9dd700 (LWP 12164)]
[New Thread 0x7fb69c8db700 (LWP 12165)]
[New Thread 0x7fb69c7d9700 (LWP 12166)]
[New Thread 0x7fb69c6d7700 (LWP 12167)]
[New Thread 0x7fb69c5d5700 (LWP 12168)]
[New Thread 0x7fb69c4d3700 (LWP 12169)]
[New Thread 0x7fb69c3d1700 (LWP 12170)]
[New Thread 0x7fb69c2cf700 (LWP 12171)]
[New Thread 0x7fb69c1cd700 (LWP 12172)]
[New Thread 0x7fb6958ef700 (LWP 12173)]
[New Thread 0x7fb6957ed700 (LWP 12174)]
[New Thread 0x7fb694eeb700 (LWP 12175)]
[New Thread 0x7fb694de9700 (LWP 12176)]
[New Thread 0x7fb694ce8700 (LWP 12177)]
[New Thread 0x7fb694be7700 (LWP 12178)]
[New Thread 0x7fb694ae6700 (LWP 12179)]
[New Thread 0x7fb6949e5700 (LWP 12180)]
[New Thread 0x7fb6948e4700 (LWP 12181)]
[New Thread 0x7fb6947e3700 (LWP 12182)]
[New Thread 0x7fb6946e2700 (LWP 12183)]
[New Thread 0x7fb6945e1700 (LWP 12184)]
[New Thread 0x7fb6944e0700 (LWP 12185)]
[New Thread 0x7fb6943df700 (LWP 12186)]
[New Thread 0x7fb6942de700 (LWP 12187)]
[New Thread 0x7fb6941dd700 (LWP 12188)]
[New Thread 0x7fb617fff700 (LWP 12189)]
[New Thread 0x7fb617efe700 (LWP 12190)]
[New Thread 0x7fb617dfd700 (LWP 12191)]
[New Thread 0x7fb617cfc700 (LWP 12192)]
[New Thread 0x7fb6177d3700 (LWP 12193)]
[New Thread 0x7fb6176d2700 (LWP 12194)]

Thread 20 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb700e09700 (LWP 12124)]
0x00007fb6d76cdffb in ?? ()
(gdb) continue
Continuing.
[Thread 0x7fb70b7dc700 (LWP 12121) exited]
[Thread 0x7fb700e09700 (LWP 12124) exited]
[Thread 0x7fb6fbfff700 (LWP 12125) exited]
[Thread 0x7fb715187700 (LWP 12120) exited]
[Thread 0x7fb715988700 (LWP 12119) exited]
[Thread 0x7fb71a189700 (LWP 12118) exited]
[Thread 0x7fb71c98a700 (LWP 12117) exited]
[Thread 0x7fb71f18b700 (LWP 12116) exited]
[Thread 0x7fb71f98c700 (LWP 12115) exited]
[Thread 0x7fb72218d700 (LWP 12114) exited]
[Thread 0x7fb72698e700 (LWP 12113) exited]
[Thread 0x7fb72718f700 (LWP 12112) exited]
[Thread 0x7fb72b990700 (LWP 12111) exited]
[Thread 0x7fb72e191700 (LWP 12110) exited]
[Thread 0x7fb732992700 (LWP 12109) exited]
[Thread 0x7fb733193700 (LWP 12108) exited]
[Thread 0x7fb733994700 (LWP 12107) exited]
[Thread 0x7fb734195700 (LWP 12106) exited]
[Thread 0x7fb6176d2700 (LWP 12194) exited]
[Thread 0x7fb617efe700 (LWP 12190) exited]
[Thread 0x7fb617fff700 (LWP 12189) exited]
[Thread 0x7fb6177d3700 (LWP 12193) exited]
[Thread 0x7fb617cfc700 (LWP 12192) exited]
[Thread 0x7fb617dfd700 (LWP 12191) exited]
[Thread 0x7fb6941dd700 (LWP 12188) exited]
[Thread 0x7fb6942de700 (LWP 12187) exited]
[Thread 0x7fb6943df700 (LWP 12186) exited]
[Thread 0x7fb6944e0700 (LWP 12185) exited]
[Thread 0x7fb6945e1700 (LWP 12184) exited]
[Thread 0x7fb6946e2700 (LWP 12183) exited]
[Thread 0x7fb6947e3700 (LWP 12182) exited]
[Thread 0x7fb6948e4700 (LWP 12181) exited]
[Thread 0x7fb6949e5700 (LWP 12180) exited]
[Thread 0x7fb694ae6700 (LWP 12179) exited]
[Thread 0x7fb694be7700 (LWP 12178) exited]
[Thread 0x7fb694ce8700 (LWP 12177) exited]
[Thread 0x7fb694de9700 (LWP 12176) exited]
[Thread 0x7fb694eeb700 (LWP 12175) exited]
[Thread 0x7fb6957ed700 (LWP 12174) exited]
[Thread 0x7fb6958ef700 (LWP 12173) exited]
[Thread 0x7fb69c1cd700 (LWP 12172) exited]
[Thread 0x7fb69c2cf700 (LWP 12171) exited]
[Thread 0x7fb69c3d1700 (LWP 12170) exited]
[Thread 0x7fb69c4d3700 (LWP 12169) exited]
[Thread 0x7fb69c5d5700 (LWP 12168) exited]
[Thread 0x7fb69c6d7700 (LWP 12167) exited]
[Thread 0x7fb69c7d9700 (LWP 12166) exited]
[Thread 0x7fb69c8db700 (LWP 12165) exited]
[Thread 0x7fb69c9dd700 (LWP 12164) exited]
[Thread 0x7fb69cadf700 (LWP 12163) exited]
[Thread 0x7fb69cbe1700 (LWP 12162) exited]
[Thread 0x7fb69cce3700 (LWP 12161) exited]
[Thread 0x7fb6ce2d7700 (LWP 12160) exited]
[Thread 0x7fb6ce3d9700 (LWP 12159) exited]
[Thread 0x7fb6ce4db700 (LWP 12158) exited]
[Thread 0x7fb6ce5dd700 (LWP 12157) exited]
[Thread 0x7fb6f8831700 (LWP 12156) exited]
[Thread 0x7fb6f8933700 (LWP 12155) exited]
[Thread 0x7fb6f8a35700 (LWP 12154) exited]
[Thread 0x7fb6f8b37700 (LWP 12153) exited]
[Thread 0x7fb6f8c39700 (LWP 12152) exited]
[Thread 0x7fb6f8d3b700 (LWP 12151) exited]
[Thread 0x7fb6f8e3d700 (LWP 12150) exited]
[Thread 0x7fb6f9041700 (LWP 12148) exited]
[Thread 0x7fb6f9143700 (LWP 12147) exited]
[Thread 0x7fb6f9245700 (LWP 12146) exited]
[Thread 0x7fb6f9347700 (LWP 12145) exited]
[Thread 0x7fb6f9449700 (LWP 12144) exited]
[Thread 0x7fb6fb7fe700 (LWP 12126) exited]
[Thread 0x7fb701838700 (LWP 12123) exited]
[Thread 0x7fb702039700 (LWP 12122) exited]
[Thread 0x7fb7341ae940 (LWP 11980) exited]
[Inferior 1 (process 11980) exited normally]
(gdb) quit


With the call to imformats the SIGSEGV occuring
for "graph.addNodes(1:1e5);" is fatal, though only after
continuing twice in gdb:


$> gdb --pid=$(ps -C octave-gui -o pid=)
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 13384
[New LWP 13510]
[New LWP 13511]
[New LWP 13512]
[New LWP 13513]
[New LWP 13514]
[New LWP 13515]
[New LWP 13516]
[New LWP 13517]
[New LWP 13518]
[New LWP 13519]
[New LWP 13520]
[New LWP 13521]
[New LWP 13522]
[New LWP 13523]
[New LWP 13524]
[New LWP 13525]
[New LWP 13528]
[New LWP 13529]
[New LWP 13530]
[New LWP 13531]
[New LWP 13532]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f68d1c7b5d9 in __GI___poll (fds=0x55e5fb8200f0, nfds=4, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) continue
Continuing.
[New Thread 0x7f6879f5f700 (LWP 13635)]
[New Thread 0x7f6879e5d700 (LWP 13636)]
[New Thread 0x7f6879d5b700 (LWP 13637)]
[New Thread 0x7f6879c59700 (LWP 13638)]
[New Thread 0x7f6879b57700 (LWP 13639)]
[New Thread 0x7f6879a55700 (LWP 13640)]
[New Thread 0x7f6879953700 (LWP 13641)]
[New Thread 0x7f6879851700 (LWP 13642)]
[New Thread 0x7f687974f700 (LWP 13643)]
[New Thread 0x7f687964d700 (LWP 13644)]
[New Thread 0x7f687954b700 (LWP 13645)]
[New Thread 0x7f6879449700 (LWP 13646)]
[New Thread 0x7f6879347700 (LWP 13647)]
[New Thread 0x7f68589b5700 (LWP 13648)]
[New Thread 0x7f68588b3700 (LWP 13649)]
[New Thread 0x7f68587b1700 (LWP 13650)]
[New Thread 0x7f68586af700 (LWP 13651)]
[New Thread 0x7f68210e7700 (LWP 13652)]
[New Thread 0x7f6820fe5700 (LWP 13653)]
[New Thread 0x7f6820ee3700 (LWP 13654)]
[New Thread 0x7f6820de1700 (LWP 13655)]
[New Thread 0x7f6820cdf700 (LWP 13656)]
[New Thread 0x7f6820bdd700 (LWP 13657)]
[New Thread 0x7f6820adb700 (LWP 13658)]
[New Thread 0x7f68209d9700 (LWP 13659)]
[New Thread 0x7f68208d7700 (LWP 13660)]
[New Thread 0x7f68207d5700 (LWP 13661)]
[New Thread 0x7f68206d3700 (LWP 13662)]
[New Thread 0x7f68205d1700 (LWP 13663)]
[New Thread 0x7f68204cf700 (LWP 13664)]
[New Thread 0x7f68203cd700 (LWP 13665)]
[New Thread 0x7f6820255700 (LWP 13666)]
[New Thread 0x7f6820153700 (LWP 13667)]
[New Thread 0x7f68117ff700 (LWP 13668)]
[New Thread 0x7f68116fe700 (LWP 13669)]
[New Thread 0x7f68115fd700 (LWP 13670)]
[New Thread 0x7f68114fc700 (LWP 13671)]
[New Thread 0x7f68113fb700 (LWP 13672)]
[New Thread 0x7f68112fa700 (LWP 13673)]
[New Thread 0x7f68111f9700 (LWP 13674)]
[New Thread 0x7f68110f8700 (LWP 13675)]
[New Thread 0x7f6810ff7700 (LWP 13676)]
[New Thread 0x7f6810ef6700 (LWP 13677)]
[New Thread 0x7f6810df5700 (LWP 13678)]
[New Thread 0x7f6810cf4700 (LWP 13679)]
[New Thread 0x7f6810bf3700 (LWP 13680)]
[New Thread 0x7f6810af2700 (LWP 13681)]
[New Thread 0x7f68109f1700 (LWP 13682)]
[New Thread 0x7f68108f0700 (LWP 13683)]
[New Thread 0x7f68103c7700 (LWP 13684)]
[New Thread 0x7f68102c6700 (LWP 13685)]

Thread 20 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f68897e4700 (LWP 13530)]
0x00007f68636ce67b in ?? ()
(gdb) bt
#0  0x00007f68636ce67b in ?? ()
#1  0x000000072d776d88 in ?? ()
#2  0x000000072d900010 in ?? ()
#3  0x00007f68897db1b0 in ?? ()
#4  0x00007f681197c0d2 in ?? ()
#5  0x00007f68897db210 in ?? ()
#6  0x00007f681197d020 in ?? ()
#7  0x00007f68897db260 in ?? ()
#8  0x00007f685bb309c0 in ?? ()
#9  0x00007f68897db260 in ?? ()
#10 0x00007f685bb309c0 in ?? ()
#11 0x000000072d900010 in ?? ()
#12 0x000000072d9000f0 in ?? ()
#13 0x000000072d776d88 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) continue
Continuing.

Thread 20 "QThread" received signal SIGSEGV, Segmentation fault.
0x00007f68636ce67b in ?? ()
(gdb) continue
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) [Thread 0x7f68102c6700 (LWP 13685) exited]
[Thread 0x7f68103c7700 (LWP 13684) exited]
[Thread 0x7f68108f0700 (LWP 13683) exited]
[Thread 0x7f68109f1700 (LWP 13682) exited]
[Thread 0x7f6810af2700 (LWP 13681) exited]
[Thread 0x7f6810bf3700 (LWP 13680) exited]
[Thread 0x7f6810cf4700 (LWP 13679) exited]
[Thread 0x7f6810df5700 (LWP 13678) exited]
[Thread 0x7f6810ef6700 (LWP 13677) exited]
[Thread 0x7f6810ff7700 (LWP 13676) exited]
[Thread 0x7f68110f8700 (LWP 13675) exited]
[Thread 0x7f68111f9700 (LWP 13674) exited]
[Thread 0x7f68112fa700 (LWP 13673) exited]
[Thread 0x7f68113fb700 (LWP 13672) exited]
[Thread 0x7f68114fc700 (LWP 13671) exited]
[Thread 0x7f68115fd700 (LWP 13670) exited]
[Thread 0x7f68116fe700 (LWP 13669) exited]
[Thread 0x7f68117ff700 (LWP 13668) exited]
[Thread 0x7f6820153700 (LWP 13667) exited]
[Thread 0x7f6820255700 (LWP 13666) exited]
[Thread 0x7f68203cd700 (LWP 13665) exited]
[Thread 0x7f68204cf700 (LWP 13664) exited]
[Thread 0x7f68205d1700 (LWP 13663) exited]
[Thread 0x7f68206d3700 (LWP 13662) exited]
[Thread 0x7f68207d5700 (LWP 13661) exited]
[Thread 0x7f68208d7700 (LWP 13660) exited]
[Thread 0x7f68209d9700 (LWP 13659) exited]
[Thread 0x7f6820adb700 (LWP 13658) exited]
[Thread 0x7f6820bdd700 (LWP 13657) exited]
[Thread 0x7f6820cdf700 (LWP 13656) exited]
[Thread 0x7f6820de1700 (LWP 13655) exited]
[Thread 0x7f6820ee3700 (LWP 13654) exited]
[Thread 0x7f6820fe5700 (LWP 13653) exited]
[Thread 0x7f68210e7700 (LWP 13652) exited]
[Thread 0x7f68586af700 (LWP 13651) exited]
[Thread 0x7f68587b1700 (LWP 13650) exited]
[Thread 0x7f68588b3700 (LWP 13649) exited]
[Thread 0x7f68589b5700 (LWP 13648) exited]
[Thread 0x7f6879347700 (LWP 13647) exited]
[Thread 0x7f6879449700 (LWP 13646) exited]
[Thread 0x7f687954b700 (LWP 13645) exited]
[Thread 0x7f687964d700 (LWP 13644) exited]
[Thread 0x7f687974f700 (LWP 13643) exited]
[Thread 0x7f6879851700 (LWP 13642) exited]
[Thread 0x7f6879953700 (LWP 13641) exited]
[Thread 0x7f6879a55700 (LWP 13640) exited]
[Thread 0x7f6879b57700 (LWP 13639) exited]
[Thread 0x7f6879c59700 (LWP 13638) exited]
[Thread 0x7f6879d5b700 (LWP 13637) exited]
[Thread 0x7f6879e5d700 (LWP 13636) exited]
[Thread 0x7f6879f5f700 (LWP 13635) exited]
[Thread 0x7f687bfff700 (LWP 13532) exited]
[Thread 0x7f6888fe3700 (LWP 13531) exited]
[Thread 0x7f68897e4700 (LWP 13530) exited]
[Thread 0x7f688a1f2700 (LWP 13529) exited]
[Thread 0x7f688a9f3700 (LWP 13528) exited]
[Thread 0x7f68942cd700 (LWP 13525) exited]
[Thread 0x7f689bc78700 (LWP 13524) exited]
[Thread 0x7f689e479700 (LWP 13523) exited]
[Thread 0x7f68a0c7a700 (LWP 13522) exited]
[Thread 0x7f68a5c7c700 (LWP 13520) exited]
[Thread 0x7f68aa47d700 (LWP 13519) exited]
[Thread 0x7f68acc7e700 (LWP 13518) exited]
[Thread 0x7f68ad47f700 (LWP 13517) exited]
[Thread 0x7f68b1c80700 (LWP 13516) exited]
[Thread 0x7f68b2481700 (LWP 13515) exited]
[Thread 0x7f68bac82700 (LWP 13514) exited]
[Thread 0x7f68bb483700 (LWP 13513) exited]
[Thread 0x7f68bbc84700 (LWP 13512) exited]
[Thread 0x7f68bc485700 (LWP 13511) exited]
[Thread 0x7f68bcc86700 (LWP 13510) exited]
[Thread 0x7f68bcc9f940 (LWP 13384) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.


Adrian <adaerr>
Thu 03 May 2018 05:14:39 PM UTC, comment #70: 

From http://www.graphicsmagick.org/NEWS.html

<<<<
Signal Handling: Signal handling is now more robust and handles SIGSEGV and other critical signals. The sole purpose of the default signal handling is to remove any temporary files and quit. An informative message is printed for signals other than SIGINT.

>>>>


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 03 May 2018 05:07:25 PM UTC, comment #69: 

BTW -- according to redhat bugzilla thread (and confirmed by java.com) -- java 9 is dead long live java 10.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Thu 03 May 2018 05:05:35 PM UTC, comment #68: 

Before the call to javaaddpath, there are two threads, the octave-cli main thread and the octave-cli signal_watcher thread.

After calling 'javaaddpath .', 32 new threads are started by Java (Java 9.0.4 in this case).

Mike Miller <mtmiller>
Group Member
Thu 03 May 2018 04:57:31 PM UTC, comment #67: 

And, add threads...

What is starting all those threads shown in the gdb transcript?  Is that the JVM or GraphicsMagick or Octave or something else?

John W. Eaton <jwe>
Group administrator
Thu 03 May 2018 04:22:12 PM UTC, comment #66: 

Yes, Octave has a way of handling SIGSEGV, and I'm starting to suspect that GraphicsMagick also has a separate SIGSEGV handler, and Java is using/handling SIGSEGV in yet another way.

Mike Miller <mtmiller>
Group Member
Thu 03 May 2018 03:56:28 PM UTC, comment #65: 

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).

Adrian <adaerr>
Thu 03 May 2018 03:24:01 PM UTC, comment #64: 

Interesting indeed. Same observations (as comment #62 and comment #63) for release-4-2-1 compiled against java-8 respectively java-9. I tried 4.2.1 specifically because I had previously (comment #34) observed that 4.2.1 behaved differently from 4.2.2. This seems to be due only to the difference in the java version that the Debian octave packages were built with (java-8 for 4.2.1, java-9 for 4.2.2).

Adrian <adaerr>
Thu 03 May 2018 07:33:08 AM UTC, comment #63: 

This might be important. With Java 9, when I comment out the call to imformats, I get the following output in gdb


(gdb) r
Starting program: /usr/bin/octave-cli --norc --silent --eval testscr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[New Thread 0x7fffc81cb700 (LWP 24096)]
[New Thread 0x7fffc3fff700 (LWP 24097)]
[New Thread 0x7fffc3efd700 (LWP 24098)]
[New Thread 0x7fffc3dfb700 (LWP 24099)]
[New Thread 0x7fffc3cf9700 (LWP 24100)]
[New Thread 0x7fffc3bf7700 (LWP 24101)]
[New Thread 0x7fffc3af5700 (LWP 24102)]
[New Thread 0x7fffc39f3700 (LWP 24103)]
[New Thread 0x7fffc30e9700 (LWP 24104)]
[New Thread 0x7fffc2fe7700 (LWP 24105)]
[New Thread 0x7fffc2ee5700 (LWP 24106)]
[New Thread 0x7fffc2de3700 (LWP 24107)]
[New Thread 0x7fffc2ce1700 (LWP 24108)]
[New Thread 0x7fffc2bdf700 (LWP 24109)]
[New Thread 0x7fffc2add700 (LWP 24110)]
[New Thread 0x7fffc29db700 (LWP 24111)]
[New Thread 0x7fffc28d9700 (LWP 24112)]
[New Thread 0x7fffc07ad700 (LWP 24113)]
[New Thread 0x7fffc06ab700 (LWP 24114)]
[New Thread 0x7fffc05a9700 (LWP 24115)]
[New Thread 0x7fff695fd700 (LWP 24116)]
[New Thread 0x7fff694fb700 (LWP 24117)]
[New Thread 0x7fff693fa700 (LWP 24118)]
[New Thread 0x7fff6907a700 (LWP 24119)]
[New Thread 0x7fff68f79700 (LWP 24120)]
[New Thread 0x7fff68e78700 (LWP 24121)]
[New Thread 0x7fff68d77700 (LWP 24122)]
[New Thread 0x7fff68c76700 (LWP 24123)]
[New Thread 0x7fff68b75700 (LWP 24124)]
[New Thread 0x7fff6864a700 (LWP 24125)]
[New Thread 0x7fff68549700 (LWP 24126)]
[New Thread 0x7fff68448700 (LWP 24127)]
N =  10
N =  100
N =  1000
N =  10000
N =  100000

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
N =  1000000
N =  10000000
N =  100000000
N =    1.0000e+09

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
warning: called from
    testscr at line 7 column 3
save to 'octave-workspace' complete

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
[Thread 0x7fff68448700 (LWP 24127) exited]
[Thread 0x7fff68549700 (LWP 24126) exited]
[Thread 0x7fff6864a700 (LWP 24125) exited]
[Thread 0x7fff68b75700 (LWP 24124) exited]
[Thread 0x7fff68c76700 (LWP 24123) exited]
[Thread 0x7fff68d77700 (LWP 24122) exited]
[Thread 0x7fff68e78700 (LWP 24121) exited]
[Thread 0x7fff68f79700 (LWP 24120) exited]
[Thread 0x7fff6907a700 (LWP 24119) exited]
[Thread 0x7fff693fa700 (LWP 24118) exited]
[Thread 0x7fff694fb700 (LWP 24117) exited]
[Thread 0x7fff695fd700 (LWP 24116) exited]
[Thread 0x7fffc05a9700 (LWP 24115) exited]
[Thread 0x7fffc06ab700 (LWP 24114) exited]
[Thread 0x7fffc07ad700 (LWP 24113) exited]
[Thread 0x7fffc28d9700 (LWP 24112) exited]
[Thread 0x7fffc29db700 (LWP 24111) exited]
[Thread 0x7fffc2add700 (LWP 24110) exited]
[Thread 0x7fffc2bdf700 (LWP 24109) exited]
[Thread 0x7fffc2ce1700 (LWP 24108) exited]
[Thread 0x7fffc2de3700 (LWP 24107) exited]
[Thread 0x7fffc2ee5700 (LWP 24106) exited]
[Thread 0x7fffc2fe7700 (LWP 24105) exited]
[Thread 0x7fffc30e9700 (LWP 24104) exited]
[Thread 0x7fffc39f3700 (LWP 24103) exited]
[Thread 0x7fffc3af5700 (LWP 24102) exited]
[Thread 0x7fffc3bf7700 (LWP 24101) exited]
[Thread 0x7fffc3cf9700 (LWP 24100) exited]
[Thread 0x7fffc3dfb700 (LWP 24099) exited]
[Thread 0x7fffc3efd700 (LWP 24098) exited]
[Thread 0x7fffc3fff700 (LWP 24097) exited]
[Thread 0x7fffc81cb700 (LWP 24096) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q


Notice the additional SIGSEGV received and handled at N=10^5. I do not see that with Java 8. It could be that this additional SIGSEGV is supposed to be a normal part of the Java stack probing behavior, that for some reason turns into a fatal signal delivered to Octave if and only if GraphicsMagick has been initialized.

That's not the only bug here, Octave should also not be able to crash even if the user tries to call a Java function with an array of size 10^20. But this difference in behavior between Java 8 and 9, which is possibly intentional, may help explain why it takes a much smaller array to cause a segfault with Java 9 or newer.

Mike Miller <mtmiller>
Group Member
Thu 03 May 2018 07:23:02 AM UTC, comment #62: 

Yes it does. I get the following.


(gdb) r
Starting program: /opt/gnu/octave/bin/octave-cli-4.2.2 --norc --silent --eval testscr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[New Thread 0x7fffd0e80700 (LWP 20364)]
[New Thread 0x7fffd0d7f700 (LWP 20365)]
[New Thread 0x7fffd0c7e700 (LWP 20366)]
[New Thread 0x7fffd0b7d700 (LWP 20367)]
[New Thread 0x7fffd0a7c700 (LWP 20368)]
[New Thread 0x7fffd097b700 (LWP 20369)]
[New Thread 0x7fffd087a700 (LWP 20370)]
[New Thread 0x7fffd0779700 (LWP 20371)]
[New Thread 0x7fffc9fe7700 (LWP 20372)]
[New Thread 0x7fffc9ee6700 (LWP 20373)]
[New Thread 0x7fffc9de5700 (LWP 20374)]
[New Thread 0x7fffc9a65700 (LWP 20375)]
[New Thread 0x7fffc9964700 (LWP 20376)]
[New Thread 0x7fffc9863700 (LWP 20377)]
[New Thread 0x7fffc9762700 (LWP 20378)]
[New Thread 0x7fffc9661700 (LWP 20379)]
[New Thread 0x7fffc9560700 (LWP 20380)]
[New Thread 0x7fffc945f700 (LWP 20381)]
N =  10
N =  100
N =  1000
N =  10000
N =  100000
N =  1000000
N =  10000000
N =  100000000
N =    1.0000e+09

Thread 1 "octave-cli-4.2." received signal SIGSEGV, Segmentation fault.


followed by an endless supply of SIGSEGV lines.

When N gets to be 10^8, it takes maybe 10 seconds of 100% busy before it prints 1e+09. At 10^9 it is still 100% busy, and after a few seconds starts printing endless screenfuls of SIGSEGV.

From what I have seen, the main difference between Java 8 and Java 9 is that Java 8 always produces a segfault when the argument is of length 10^9, whether a GraphicsMagick function has been called yet or not. That's the same behavior I see with Java 9 when a GraphicsMagick function has not been called. With Java 9, the size to produce a segfault is reduced to 10^5 after a GraphicsMagick function has been called. That's basically what I described in comment #60.

The "endless supply of SIGSEGV lines" symptom only occurs when running with gdb when imformats or some other GraphicsMagick function has been called. If no image functions are called, the segmentation fault always occurs at N=10^9, and it is only a single SIGSEGV message along with Octave's "stopping myself" diagnostic message.

Mike Miller <mtmiller>
Group Member
Thu 03 May 2018 06:12:25 AM UTC, comment #61: 

@Mike Miller: I'd be curious to know whether the Octave 4.2.2 linked with OpenJDK 8 that you mentioned in comment #3 still produces a segfault in gdb once the SIGSEGV generated by the JVM for stack overflow detection have been made non-fatal in gdb ("handle SIGSEGV nostop print pass" in .gdbinit).

Here's again the modification of the test from comment #59 that probes various argument sizes:


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


Adrian <adaerr>
Tue 01 May 2018 09:56:48 PM UTC, comment #60: 

The GraphicsMagick code isn't in a loadable dldfcn oct file anymore, it's in builtin functions now.

So based on what we've found so far, if I had to summarize this, it's that it has to do with passing large arrays in to Java functions via JNI. There is some size at which Octave goes into a 100% busy state (and never returns? takes an exponentially long time?) but does not crash. And there is some larger size at which Octave crashes immediately with a SIGSEGV.

For some as-yet-unknown reason, calling any GraphicsMagick functions in Octave before the Java function is called drastically reduces these size limits.

Ideally, Octave would know about this limit or be able to detect this condition dynamically and print an error message that some size threshold has been crossed and avoid the segmentation fault.

Mike Miller <mtmiller>
Group Member
Mon 30 Apr 2018 11:20:54 PM UTC, comment #59: 

All the following is on a box with an Intel Core i5-2500K CPU, on which under gdb the 'javaaddpath (".")' instruction terminates the octave process:

octave:1> javaaddpath (".")

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc6c85700 (LWP 23040)]
0x00007fff97a2a4f3 in ?? ()
(gdb)


I can confirm that creating a .gdbinit containing "handle SIGSEGV nostop print
pass" makes octave survive the first SIGSEGV, but line 4 is still
fatal with the same signal:


> gdb --args octave --norc --no-gui
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave...(no debugging symbols found)...done.
(gdb) javaaddpath (".")
Undefined command: "javaaddpath".  Try "help".
(gdb) run
Starting program: /usr/bin/octave --norc --no-gui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
process 22977 is executing new program: /usr/lib/x86_64-linux-gnu/octave/4.2.2/exec/x86_64-pc-linux-gnu/octave-gui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdf465700 (LWP 22981)]
[New Thread 0x7fffdec64700 (LWP 22982)]
[New Thread 0x7fffda463700 (LWP 22983)]
[New Thread 0x7fffd1edc700 (LWP 22984)]
[New Thread 0x7fffc7c87700 (LWP 22985)]
[New Thread 0x7fffc7486700 (LWP 22986)]
[New Thread 0x7fffc6c85700 (LWP 22987)]
[New Thread 0x7fffc6484700 (LWP 22988)]
GNU Octave, version 4.2.2
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> javaaddpath (".")

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[New Thread 0x7fffb7d0e700 (LWP 22989)]
[New Thread 0x7fffb7c0c700 (LWP 22990)]
[New Thread 0x7fffb7b0a700 (LWP 22991)]
[New Thread 0x7fffb7a08700 (LWP 22992)]
[New Thread 0x7fffb7906700 (LWP 22993)]
[New Thread 0x7fffb7804700 (LWP 22994)]
[New Thread 0x7fffb7702700 (LWP 22995)]
[New Thread 0x7fffb7600700 (LWP 22996)]
[New Thread 0x7fffb74fe700 (LWP 22997)]
[New Thread 0x7fffb53d6700 (LWP 22998)]
[New Thread 0x7fffb52d4700 (LWP 22999)]
[New Thread 0x7fffb49d2700 (LWP 23000)]
[New Thread 0x7fffb48d0700 (LWP 23001)]
[New Thread 0x7fffb47cf700 (LWP 23002)]
[New Thread 0x7fffb46ce700 (LWP 23003)]
[New Thread 0x7fffb45cd700 (LWP 23004)]
[New Thread 0x7fffb44cc700 (LWP 23005)]
[New Thread 0x7fffb43cb700 (LWP 23006)]
[New Thread 0x7fffb42ca700 (LWP 23007)]
[New Thread 0x7fffb41c9700 (LWP 23008)]
[New Thread 0x7fff955ff700 (LWP 23009)]
[New Thread 0x7fff954fe700 (LWP 23010)]
octave:2> fmt = imformats ();
octave:3> graph = javaObject ("Baz");
octave:4> graph.addNodes (1:1e8);

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
save to 'octave-workspace' complete

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Thread 0x7fff954fe700 (LWP 23010) exited]
[Thread 0x7fff955ff700 (LWP 23009) exited]
[Thread 0x7fffb41c9700 (LWP 23008) exited]
[Thread 0x7fffb42ca700 (LWP 23007) exited]
[Thread 0x7fffb43cb700 (LWP 23006) exited]
[Thread 0x7fffb44cc700 (LWP 23005) exited]
[Thread 0x7fffb45cd700 (LWP 23004) exited]
[Thread 0x7fffb46ce700 (LWP 23003) exited]
[Thread 0x7fffb47cf700 (LWP 23002) exited]
[Thread 0x7fffb48d0700 (LWP 23001) exited]
[Thread 0x7fffb49d2700 (LWP 23000) exited]
[Thread 0x7fffb53d6700 (LWP 22998) exited]
[Thread 0x7fffb74fe700 (LWP 22997) exited]
[Thread 0x7fffb7600700 (LWP 22996) exited]
[Thread 0x7fffb7702700 (LWP 22995) exited]
[Thread 0x7fffb7804700 (LWP 22994) exited]
[Thread 0x7fffb7906700 (LWP 22993) exited]
[Thread 0x7fffb7a08700 (LWP 22992) exited]
[Thread 0x7fffb7b0a700 (LWP 22991) exited]
[Thread 0x7fffb7c0c700 (LWP 22990) exited]
[Thread 0x7fffb7d0e700 (LWP 22989) exited]
[Thread 0x7fffc6484700 (LWP 22988) exited]
[Thread 0x7fffc6c85700 (LWP 22987) exited]
[Thread 0x7fffc7486700 (LWP 22986) exited]
[Thread 0x7fffc7c87700 (LWP 22985) exited]
[Thread 0x7fffd1edc700 (LWP 22984) exited]
[Thread 0x7fffda463700 (LWP 22983) exited]
[Thread 0x7fffdec64700 (LWP 22982) exited]
[Thread 0x7fffdf465700 (LWP 22981) exited]
[Thread 0x7ffff7f9b940 (LWP 22977) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)


For completeness, outside gdb the script from comment #58 always
produces a segfault in line 4, whether with the .gdbinit "handle
SIGSEGV nostop print pass" configuration or ot, and whether run via
"octave --norc --no-gui comment58.m" or "octave-cli --norc
comment58.m":

panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
warning: called from
    comment58 at line 4 column 1
save to 'octave-workspace' complete


A modified script changing the argument size along the lines of
what Dmitri did, namely:

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


  • outside gdb either segfaults or freezes (CPU load->100%) for k=5 / N=1e5,
  • inside gdb, with "handle SIGSEGV nostop print pass" in .gdbinit (otherwise as usual segfault at first line), shows a curious behaviour:



> gdb --args octave --no-gui --norc comment58inc.m
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/octave --no-gui --norc comment58inc.m
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
process 23356 is executing new program: /usr/lib/x86_64-linux-gnu/octave/4.2.2/exec/x86_64-pc-linux-gnu/octave-gui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdf465700 (LWP 23360)]
[New Thread 0x7fffdcc64700 (LWP 23361)]
[New Thread 0x7fffdc463700 (LWP 23362)]
[New Thread 0x7fffd1edc700 (LWP 23363)]
[New Thread 0x7fffc7c87700 (LWP 23364)]
[New Thread 0x7fffc7486700 (LWP 23365)]
[New Thread 0x7fffc6c85700 (LWP 23366)]
[New Thread 0x7fffc6484700 (LWP 23367)]

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[New Thread 0x7fffb7d0e700 (LWP 23368)]
[New Thread 0x7fffb7c0c700 (LWP 23369)]
[New Thread 0x7fffb7b0a700 (LWP 23370)]
[New Thread 0x7fffb7a08700 (LWP 23371)]
[New Thread 0x7fffb7906700 (LWP 23372)]
[New Thread 0x7fffb7804700 (LWP 23373)]
[New Thread 0x7fffb7702700 (LWP 23374)]
[New Thread 0x7fffb7600700 (LWP 23375)]
[New Thread 0x7fffb74fe700 (LWP 23376)]
[New Thread 0x7fffb53d6700 (LWP 23377)]
[New Thread 0x7fffb52d4700 (LWP 23378)]
[New Thread 0x7fffb49d2700 (LWP 23379)]
[New Thread 0x7fffb48d0700 (LWP 23380)]
[New Thread 0x7fffb47cf700 (LWP 23381)]
[New Thread 0x7fffb46ce700 (LWP 23382)]
[New Thread 0x7fffb45cd700 (LWP 23383)]
[New Thread 0x7fffb44cc700 (LWP 23384)]
[New Thread 0x7fffb43cb700 (LWP 23385)]
[New Thread 0x7fffb42ca700 (LWP 23386)]
[New Thread 0x7fffb41c9700 (LWP 23387)]
[New Thread 0x7fff955ff700 (LWP 23388)]
[New Thread 0x7fff954fe700 (LWP 23389)]
N =  10
N =  100
N =  1000
N =  10000
N =  100000

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.

---Type <return> to continue, or q <return> to quit---


The last line is the pager offering me as many pages of segfault
messages as I had patience scrolling through, and when I quit it
typing 'q <return>', I return to the gdb prompt.

So according to Rik's explanation a large number of SIGSEGV are just caught inside the JVM for overflow detection. But what causes one signal to be eventually passed on to octave (or so it seems) ?

Adrian <adaerr>
Mon 30 Apr 2018 06:46:56 PM UTC, comment #58: 

Well, that is interesting.  Of course, executing just imformats is enough to load in the GraphicsMagick dldfcn, as well as execute some pretty intricate code with persistent variables in subfunctions for which mlock has been called.

It would help if the original reporter could verify the new proposed test code still produces a segfault.


javaaddpath (".")
fmt = imformats ();
graph = javaObject ("Baz");
graph.addNodes (1:1e8);



Rik <rik5>
Group administrator
Mon 30 Apr 2018 06:22:25 PM UTC, comment #57: 

I don't know. But removing the call to imwrite makes a larger sized argument


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


work just fine. It takes a while and is busy most of the time, doing Octave-to-Java array type conversion I suspect, but exits without error.

Simply calling 'imformats' to print the image format types supported by GraphicsMagick, instead of imwrite, is enough to allow the 1:1e6 argument to lead to a segfault.

Mike Miller <mtmiller>
Group Member
Mon 30 Apr 2018 06:08:10 PM UTC, comment #56: 

@Mike: is this just due to a difference in the amount of memory reserved for the JVM between versions 8 and 9?  The fact that changing the Java code to use less memory stops the segfault is suggestive.

Rik <rik5>
Group administrator
Mon 30 Apr 2018 06:01:52 PM UTC, comment #55: 

The same test code still causes a segfault in Octave for me.

With Octave 4.2.2 linked with Java 8, I get no segfault.

With Octave 4.2.2 linked with Java 9:


$ octave-cli --norc crashtest.m
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
warning: called from
    crashtest at line 4 column 1
save to 'octave-workspace' complete
Segmentation fault


With Octave 4.3.92 linked with Java 9:


$ octave-cli --norc crashtest.m
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault


If I reduce the size of the array passed in to addNodes, I get no segfault.

My processor is Intel(R) Core(TM) i7-4770HQ.

Mike Miller <mtmiller>
Group Member
Mon 30 Apr 2018 05:48:17 PM UTC, comment #54: 

I added the following to my local .gdbinit


handle SIGSEGV nostop print pass


In this case, I get a printout about the segmentation fault which is used internally by JVM for overflow detection, but it doesn't cause gdb to immediately abort.  I am also using the pass option, so a true SIGSEGV would be passed to enclosing program which created the JVM if it were real.  But, this doesn't happen indicating that it is a spurious thing.

I ran both the tiny test program, and also Octave, and neither issues more than one SIGSEGV (associated with the startup of the JVM).  The test code in Octave I used was


javaaddpath(".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
graph.addNodes(1:1000000);


Also, without gdb the code above runs fine multiple times using


run-octave -f crashtest.m


Don't know if it was the case that the original reporter was running with the '-f' flag to prevent user customizations in .octaverc which might actually be triggering this.

Rik <rik5>
Group administrator
Mon 30 Apr 2018 02:04:33 PM UTC, comment #53: 

I filled the bug on redhat bugzilla. Please have a look at the discussion. It is above my head:

https://bugzilla.redhat.com/show_bug.cgi?id=1572811

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 29 Apr 2018 10:06:10 PM UTC, comment #52: 

Sorry, bug in the code of comment #50, second line in main() should allocate space for two options,


JavaVMOption* options = new JavaVMOption[2];


This does not change the rest of the observations, and the program still produces a segfault under gdb. As said before, the code is mainly the example from the JNI JVM-invocation documentation at

https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html

Adrian <adaerr>
Sun 29 Apr 2018 09:57:03 PM UTC, comment #51: 

Submit bug report to OpenJDK ?

The Java issues that were cited here consider the Segfault at JVM creation resolved since basically summer 2017, so the issues are closed. Notably
https://bugs.openjdk.java.net/browse/JDK-8183188
observed the bug on a Xeon X5675 processor, where indeed the simple program now executes flawlessly. Wouldn't it be worthwhile re-opening the bug or submitting a new issue on the fact that the test program still fails under gdb on certain processors (possibly for a different reason)? This seriously hampers debugging of programs using jvm-functionnality, as here, and also indicates that something is still rotten in the land of JNI. However it would probably be better if someone more knowledgeable than me in Java/JNI-matters and generally in programming reported the bug. :-)

[Never mind the question in my previous comment: I imagine that if it were easy to link octave with a non-openjdk JVM you'd have tried that.]

Adrian <adaerr>
Sun 29 Apr 2018 05:57:40 AM UTC, comment #50: 

Just to share a 'negative' result, I tried to implement the workaround mentioned on

https://issues.apache.org/jira/browse/DAEMON-363

(linked to by the openjdk bug referenced by John in comment #12 and comment #17)

Namely to increase the Java stack size by the option "-Xss2m". I have no clue how the stack guard works and how it affects JVMs, nor how this option would circumvent the problem, but it seems openjdk does not implement the -Xss option anyway. Maybe it would be worth trying a JRE that implements it ?

Source code to be compiled with

g++ -ggdb3 -I/usr/lib/jvm/java-9-openjdk-amd64/include -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux jni_createVM_test.c -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm -o jni_createVM_test_openjdk-9Xss2m



#include <jni.h>
#include <stdlib.h>

int
main (void)
{
  JavaVMInitArgs vmArgs;
  JavaVMOption* options = new JavaVMOption[1];

  options[0].optionString = "-Xss2m";
  options[1].optionString = "-verbose:jni";

  vmArgs.version = JNI_VERSION_1_8;
  vmArgs.nOptions = 2;
  vmArgs.options = options;
  vmArgs.ignoreUnrecognized = JNI_FALSE;

  JNIEnv *env = NULL;
  JavaVM *jvm = NULL;

  jint ret = JNI_CreateJavaVM (&jvm, (void **) &env, &vmArgs);
  if (ret < 0 || jvm == NULL)
    {
      printf ("failed\n");
      //log(0, "Unable to create a Java Virtual Machine");
      return -1;
    }

  printf ("VM = %p\n", jvm);

  return 0;
}


Adrian <adaerr>
Sat 28 Apr 2018 10:52:01 PM UTC, comment #49: 

Sorry -- it was cut-n-paste error with the previous code.

Here is the test code:



javaaddpath (".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
for jj=1:100
       N = 1000*jj
       tic; graph.addNodes(1:N); toc
endfor


Running standalone I got:

octave:1> tjava
N =  1000
Elapsed time is 0.00399303 seconds.
N =  2000
Elapsed time is 0.00136709 seconds.
N =  3000
Elapsed time is 0.00197601 seconds.
N =  4000
Elapsed time is 0.00241995 seconds.
N =  5000
Elapsed time is 0.00188708 seconds.
N =  6000
Elapsed time is 0.00217009 seconds.
N =  7000
Elapsed time is 0.00244117 seconds.
N =  8000
Elapsed time is 0.00257707 seconds.
N =  9000
Killed

(It hanged after N=9000 and i had to kill -9 it)

running under gdb I got:

octave:1> tjava
[New Thread 0x7fffb2035700 (LWP 3230)]
[New Thread 0x7fffb1f33700 (LWP 3231)]
[New Thread 0x7fffb1c2f700 (LWP 3232)]
[New Thread 0x7fffb1b2d700 (LWP 3233)]
[New Thread 0x7fffb1a2b700 (LWP 3234)]
[New Thread 0x7fffb09a5700 (LWP 3235)]
[New Thread 0x7fffb08a3700 (LWP 3236)]
[New Thread 0x7fffb0529700 (LWP 3237)]
[New Thread 0x7fffb0427700 (LWP 3238)]
[New Thread 0x7fffb0326700 (LWP 3239)]
[New Thread 0x7fffb0225700 (LWP 3240)]
[New Thread 0x7fffb0124700 (LWP 3241)]
[New Thread 0x7fff91326700 (LWP 3242)]
[New Thread 0x7fff91225700 (LWP 3243)]
[New Thread 0x7fff90cfa700 (LWP 3244)]
[New Thread 0x7fff90bf9700 (LWP 3245)]
[New Thread 0x7fff90af8700 (LWP 3246)]
[New Thread 0x7fff68ae4700 (LWP 3247)]
N =  1000
Elapsed time is 0.00256085 seconds.
N =  2000
Elapsed time is 0.00192499 seconds.
N =  3000
Elapsed time is 0.00288796 seconds.
N =  4000
Elapsed time is 0.00139713 seconds.
N =  5000
Elapsed time is 0.0035069 seconds.
N =  6000

Thread 7 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc0e51700 (LWP 3228)]
0x00007fff9b4ff09b in ?? ()
Missing separate debuginfos...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Apr 2018 09:15:13 PM UTC, comment #48: 

So there is no crash but CPU hogging for the original code, right ? This is one of the two behaviours I observe for octave outside gdb. Does it (the original code, including graph.addNodes) also hog CPU when run under gdb ?

In your modified code you omit the method call

graph.addNodes(1:1000000);

which is the only problematic when running freely, and in gdb on systems where one gets past the "javaaddpath('.')". Not sure therfore what your testing of the imwrite timing is supposed to show: it's certainly not nice that imwrite or zeros cause termination instead of some recoverable out of memory error, but I have the impression it has nothing to do with the segfault that this bug-report is about.

Adrian <adaerr>
Sat 28 Apr 2018 08:19:59 PM UTC, comment #47: 

It runs pretty much the same under gdb. I noticed that octave RES memory went to ~6GB at around N=20000 and the computer started to swap (it has "only" 8 GB of RAM).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Apr 2018 08:08:25 PM UTC, comment #46: 

No crash on

vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU     T9900  @ 3.06GHz
stepping : 10
microcode : 0xa0b
cpu MHz : 1595.627
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm ida
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 6116.57
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

The original code hogged the CPU and I had to kill -9 it after ~30 minutes.
Then I modified the code as follows:



cat tjava.m
javaaddpath (".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
for jj=1:100
       N = 1000*jj
       tic; imwrite(zeros(1000*jj), "foo.png"); toc
endfor


and I got:

octave:1> tjava
N =  1000
Elapsed time is 0.126127 seconds.
N =  2000
Elapsed time is 0.513371 seconds.
N =  3000
Elapsed time is 1.0897 seconds.
N =  4000
Elapsed time is 1.89885 seconds.
N =  5000
Elapsed time is 3.00135 seconds.
N =  6000
Elapsed time is 4.31079 seconds.
N =  7000
Elapsed time is 5.73707 seconds.
N =  8000
Elapsed time is 7.74923 seconds.
N =  9000
Elapsed time is 9.53925 seconds.
N =  10000
Elapsed time is 11.7024 seconds.
N =  11000
Elapsed time is 14.1665 seconds.
N =  12000
Elapsed time is 17.2648 seconds.
N =  13000
Elapsed time is 20.0761 seconds.
N =  14000
Elapsed time is 22.8917 seconds.
N =  15000
Elapsed time is 26.3692 seconds.
N =  16000
Elapsed time is 36.8092 seconds.
N =  17000
Elapsed time is 34.7174 seconds.
N =  18000
Elapsed time is 48.9227 seconds.
N =  19000
Elapsed time is 62.3376 seconds.
N =  20000
Elapsed time is 73.7005 seconds.
N =  21000
Elapsed time is 72.4562 seconds.
N =  22000
fatal: caught signal Terminated -- stopping myself...
attempting to save variables to 'octave-workspace'...
warning: save: unable to save java objects, skipping
warning: called from
    _imwrite_ at line 215 column 3
    imwrite at line 119 column 5
    tjava at line 6 column 13
save to 'octave-workspace' complete

(I kill it with signal 15 at the end.)
Notice the time increase is not uniform.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Apr 2018 05:44:37 PM UTC, comment #45: 

I think it is Java bug in cpu probe code. We have seen this before
with ASAN
https://savannah.gnu.org/bugs/?52061
and that happened before Spectre/Meltdown brouhaha.

I am away from Xeon at the moment, but should be able to test on Core2duo laptop shortly. (The test program runs fine there.)

BTW AMD FX-8350 crashes as well.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 28 Apr 2018 02:30:07 PM UTC, comment #44: 

I would also like to know the results of testing a system working with gdb with the OP's code (comment #43).

This may be a red herring, but is this related to Spectre and Meltdown and subsequent microcode patches by Intel?

Using 'cat /proc/cpuinfo' I find that my system is


processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 78
model name      : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
stepping        : 3
microcode       : 0xc2


It is an i7 and crashes, just as Adrian's i5 system crashes.

An additional field that I have never noticed in the output is


bugs            : cpu_meltdown spectre_v1 spectre_v2


I see that there were also reports of HW instability with the first microcode update from Intel for Ubuntu (https://news.softpedia.com/news/canonical-pulls-intel-s-microcode-update-from-ubuntu-repos-due-to-hardware-issue-519494.shtml).  Maybe something is still not complely correct.

Rik <rik5>
Group administrator
Sat 28 Apr 2018 01:42:03 PM UTC, comment #43: 

I can also confirm that the small test program crashes on an Intel i7-6600U.

In response to Rik's remark (comment #31), I upgraded gdb to 8.0 (the version currently shipped in Debian-experimental) on both the Xeon and the Intel i5 system: the behaviour remains the same (no error on Xeon, segfault on i5).

@Dmitri A. Sergatskov: I'd be curious like Rik (comment #31) to know whether you see the bug I reported, on your Xeon system where the small standalone program runs fine. That is, if octave (in gdb or not) crashes (and when) if given the commands


javaaddpath(".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
graph.addNodes(1:1000000);


As Rik commented, whatever the result does not really tell us if this is related to the same bug or not, but it would give a better idea on the reproductibility of this particular test. Up to here Mike Miller seems to have observed the same bug (from the way I read his comment #3), but both Rik and John W. Eaton see a segfault much earlier under gdb.

Adrian <adaerr>
Sat 28 Apr 2018 12:14:58 AM UTC, comment #42: 

Aha, nice observation Dmitri. Concerning my tests the program runs fine (under gdb) on a
model name      : Intel(R) Xeon(R) CPU           E5520
and crashes on a
model name      : Intel(R) Core(TM) i5-2500K CPU

Adrian <adaerr>
Fri 27 Apr 2018 11:35:11 PM UTC, comment #41: 

So it looks like it is CPU dependent -- it crashes on i7 and runs fine on an old Nehalem-based Xeon (W3530) and on Core2 duo.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 27 Apr 2018 11:12:42 PM UTC, comment #40: 

Now I have the small program to crash. It was a bunch of updates including a new(ish) kernel...


 LD_LIBRARY_PATH=/usr/lib/jvm/java-9/lib/server gdb ./a.out
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) r
Starting program: /home/dima/scratch/tjava/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdc60a4f3 in ?? ()
(gdb) bt
#0  0x00007fffdc60a4f3 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007fffdc60a280 in ?? ()
#3  0x00007ffff7d8cf04 in Abstract_VM_Version::_vm_major_version () from /usr/lib/jvm/java-9/lib/server/libjvm.so
#4  0x00007fffffffc9d0 in ?? ()
#5  0x00007ffff7885bc9 in VM_Version::get_processor_features ()
    at /usr/src/debug/java-9-openjdk-9.0.4.11-6.fc28.x86_64/openjdk/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:530
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


The 530 line of that file is:

  get_cpu_info_stub(&_cpuid_info);


This all looks awfully familiar.
https://savannah.gnu.org/bugs/?52061

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Fri 27 Apr 2018 10:07:58 PM UTC, comment #39: 

I was finally able to get a different result out of gdb with the small test program.

I created a local .gdbinit file with the following


set auto-load python-scripts off


Now, I can compile and run the test program and the backtrace has a bit more meaning.


(gdb) run
Starting program: /home/rik/wip/Projects_Mine/octave-bugs/jvm/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe5b5c2b4 in ?? ()
(gdb) bt
#0  0x00007fffe5b5c2b4 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007fffe5b5c160 in ?? ()
#3  0x00007ffff7dd525c in Abstract_VM_Version::_reserve_for_allocation_prefetch ()
   from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#4  0x00007fffffffdc30 in ?? ()
#5  0x00007ffff790965d in VM_Version::get_cpu_info_wrapper ()
    at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
#6  VM_Version::get_processor_features ()
    at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:417
#7  0x49656e696c65746e in ?? ()
#8  0x00100800000406e3 in ?? ()
#9  0xbfebfbff7ffafbbf in ?? ()
#10 0x01c0003f1c004121 in ?? ()
#11 0x000000000000003f in ?? ()
#12 0x0000000000000000 in ?? ()


Of course, without gdb this runs just fine.

Rik <rik5>
Group administrator
Fri 27 Apr 2018 09:56:51 PM UTC, comment #38: 

@ John W. Eaton / comment 36: On another machine I see the small program behaving as you describe (ok without gdb, segfault in gdb). Now I have to find what distinguishes this computer from the one which runs the same binary just fine.

Adrian <adaerr>
Fri 27 Apr 2018 09:47:58 PM UTC, comment #37: 

This is really puzzling, as the small program from comment #12 works well with or without gdb on my current system (octave 4.2.2, kernel 4.9 or 4.15), as I reported in comment #28. I even just upgraded gdb from 7.12-6 to 7.12-6-b1 to match the version of yours (this also draws in libpython3.6-minimal, libpython3.6-stdlib and libpython3.6), but still it does not produce any error and exits normally.

Adrian <adaerr>
Fri 27 Apr 2018 09:23:30 PM UTC, comment #36: 

The thing that would shed more light is to understand why the smaller test program also crashes.  Show me how to make that work reliably with or without gdb.  Since it is much simpler, that should be a far easier task than trying to debug the crash in Octave.


John W. Eaton <jwe>
Group administrator
Fri 27 Apr 2018 09:23:22 PM UTC, comment #35: 

Sorry, comment #34 was missing its footnote, namely the packages affected by the upgrade from octave 4.2.1 to 4.2.2:

[*] The upgrade of octave from 4.2.1 to 4.2.2 implied an upgrade to the following packages. All other packages where held (in particular the kernel and openjdk packages). Citing the relevant part from /var/log/aptitude:


Aptitude 0.8.10: log report
Tue, Apr 24 2018 13:06:58 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 12 packages, and remove 0 packages.
5145 kB of disk space will be used
========================================
[HOLD, DEPENDENCIES] apparmor:amd64 2.12-2
[snip]
[HOLD] zsh-common:amd64 5.4.2-3
[UPGRADE] libc-bin:amd64 2.26-6 -> 2.27-3
[UPGRADE] libc-dev-bin:amd64 2.26-6 -> 2.27-3
[UPGRADE] libc-l10n:amd64 2.26-6 -> 2.27-3
[UPGRADE] libc6:amd64 2.26-6 -> 2.27-3
[UPGRADE] libc6-dbg:amd64 2.26-6 -> 2.27-3
[UPGRADE] libc6-dev:amd64 2.26-6 -> 2.27-3
[UPGRADE] liboctave4:amd64 4.2.1-7 -> 4.2.2-2
[UPGRADE] locales:amd64 2.26-6 -> 2.27-3
[UPGRADE] octave:amd64 4.2.1-7 -> 4.2.2-2
[UPGRADE] octave-common:amd64 4.2.1-7 -> 4.2.2-2
[UPGRADE] octave-control:amd64 3.0.0-5 -> 3.1.0-2
[UPGRADE] octave-io:amd64 2.4.10-2 -> 2.4.10-3
========================================

Log complete.

===============================================================================


Adrian <adaerr>
Fri 27 Apr 2018 09:16:56 PM UTC, comment #34: 

Checking back, the single out of four GNU/Linux systems where the
originally reported bug did not seem to occur (see comment #1) was in
fact not as up-to-date as the others: its kernel was at 4.14 and
octave at 4.2.1. It executed the instructions cited at the start of
comment #1 without error. I did unfortunately not think of running it
from within gdb to see if that changed things. Once I selectively
upgraded octave to 4.2.2[*], still running the 4.14 kernel, this
system also exhibited the bug reported in comment #1.

So with this correction, the bug seems to be totally reproducible with
octave 4.2.2 on four Debian systems (1 stretch, 3 buster). When
running octave under gdb, the bug is a SIGSEGV signal upon execution
of the fourth and last line of the following code:


javaaddpath(".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
graph.addNodes(1:1000000);


When octave is run directly without attaching gdb (in GUI or CLI
mode), the bug also occurs. but on two systems leads to an application
crash with the signal 11 / SIGSEGV reported by the controlling
terminal, while on two other systems the interface freezes (the
octave-gui process ramps up to 100% CPU usage until killed).

So it seems that this bug could be (at least on Debian systems) a
regression in octave 4.2.2, not occuring on octave 4.0.3 and 4.2.1.

Let me know if some other test could help shed more light. I'll
upgrade gdb to the version used by Dmitri to see if that changes
things.

Adrian <adaerr>
Fri 27 Apr 2018 09:15:44 PM UTC, comment #33: 

@John W. Eaton / comment #30: Yes, octave-cli under gdb fails the test (output below).

octave-cli however executes the instructions  and returns to a prompt when not run under gdb, contrary to 'octave --no-gui'. Aren't those equivalent ?


$> gdb --args octave-cli --norc
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave-cli...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/octave-cli --norc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe1578700 (LWP 9638)]
[New Thread 0x7fffe0d77700 (LWP 9639)]
[New Thread 0x7fffde576700 (LWP 9640)]
[New Thread 0x7fffd9d75700 (LWP 9641)]
[New Thread 0x7fffd9574700 (LWP 9642)]
[New Thread 0x7fffd4d73700 (LWP 9643)]
[New Thread 0x7fffd4572700 (LWP 9644)]
[New Thread 0x7fffcfd71700 (LWP 9645)]
[New Thread 0x7fffcd570700 (LWP 9646)]
[New Thread 0x7fffccd6f700 (LWP 9647)]
[New Thread 0x7fffc856e700 (LWP 9648)]
[New Thread 0x7fffc5d6d700 (LWP 9649)]
[New Thread 0x7fffc356c700 (LWP 9650)]
[New Thread 0x7fffc0d6b700 (LWP 9651)]
[New Thread 0x7fffbe56a700 (LWP 9652)]
GNU Octave, version 4.2.2
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> javaaddpath(".")
[New Thread 0x7fff9eef5700 (LWP 9653)]
[New Thread 0x7fff9edf3700 (LWP 9654)]
[New Thread 0x7fff9ecf1700 (LWP 9655)]
[New Thread 0x7fff9ebef700 (LWP 9656)]
[New Thread 0x7fff9eaed700 (LWP 9657)]
[New Thread 0x7fff9e9eb700 (LWP 9658)]
[New Thread 0x7fff9e8e9700 (LWP 9659)]
[New Thread 0x7fff9e7e7700 (LWP 9660)]
[New Thread 0x7fff9e6e5700 (LWP 9661)]
[New Thread 0x7fff9e5e3700 (LWP 9662)]
[New Thread 0x7fff9e4e1700 (LWP 9663)]
[New Thread 0x7fff9e3df700 (LWP 9664)]
[New Thread 0x7fff9e2dd700 (LWP 9665)]
[New Thread 0x7fff9d4ce700 (LWP 9666)]
[New Thread 0x7fff9d3cc700 (LWP 9667)]
[New Thread 0x7fff9d2ca700 (LWP 9668)]
[New Thread 0x7fff9d1c8700 (LWP 9669)]
[New Thread 0x7fff9d0c6700 (LWP 9670)]
[New Thread 0x7fff9cfc4700 (LWP 9671)]
[New Thread 0x7fff9cec2700 (LWP 9672)]
[New Thread 0x7fff9cdc0700 (LWP 9673)]
[New Thread 0x7fff9ccbe700 (LWP 9674)]
[New Thread 0x7fff9cbbc700 (LWP 9675)]
[New Thread 0x7fff9caba700 (LWP 9676)]
[New Thread 0x7fff9c9b8700 (LWP 9677)]
[New Thread 0x7fff9c8b6700 (LWP 9678)]
[New Thread 0x7fff9c7b4700 (LWP 9679)]
[New Thread 0x7fff2a339700 (LWP 9680)]
[New Thread 0x7fff2a237700 (LWP 9681)]
[New Thread 0x7fff2a135700 (LWP 9682)]
[New Thread 0x7fff2a033700 (LWP 9683)]
[New Thread 0x7fff289ae700 (LWP 9684)]
[New Thread 0x7fff288ac700 (LWP 9685)]
[New Thread 0x7fff287ab700 (LWP 9686)]
[New Thread 0x7fff286aa700 (LWP 9687)]
[New Thread 0x7fff285a9700 (LWP 9688)]
[New Thread 0x7fff284a8700 (LWP 9689)]
[New Thread 0x7fff283a7700 (LWP 9690)]
[New Thread 0x7fff282a6700 (LWP 9691)]
[New Thread 0x7fff281a5700 (LWP 9692)]
[New Thread 0x7fff19fff700 (LWP 9693)]
[New Thread 0x7fff19efe700 (LWP 9694)]
[New Thread 0x7fff19dfd700 (LWP 9695)]
[New Thread 0x7fff19cfc700 (LWP 9696)]
[New Thread 0x7fff19bfb700 (LWP 9697)]
[New Thread 0x7fff19afa700 (LWP 9698)]
[New Thread 0x7fff199f9700 (LWP 9699)]
[New Thread 0x7fff198f8700 (LWP 9700)]
[New Thread 0x7fff193cd700 (LWP 9701)]
[New Thread 0x7fff192cc700 (LWP 9702)]
[New Thread 0x7fff191cb700 (LWP 9703)]
octave:2> imwrite(zeros(1000), "foo.png");
[New Thread 0x7ffec7675700 (LWP 9704)]
[New Thread 0x7ffec6e74700 (LWP 9705)]
[New Thread 0x7ffec6673700 (LWP 9706)]
[New Thread 0x7ffec5e72700 (LWP 9707)]
[New Thread 0x7ffec5671700 (LWP 9708)]
[New Thread 0x7ffec4e70700 (LWP 9709)]
[New Thread 0x7ffebffff700 (LWP 9710)]
[New Thread 0x7ffebf7fe700 (LWP 9711)]
[New Thread 0x7ffebeffd700 (LWP 9712)]
[New Thread 0x7ffebe7fc700 (LWP 9713)]
[New Thread 0x7ffebdffb700 (LWP 9714)]
[New Thread 0x7ffebd7fa700 (LWP 9715)]
[New Thread 0x7ffebcff9700 (LWP 9716)]
[New Thread 0x7ffebc7f8700 (LWP 9717)]
[New Thread 0x7ffebbff7700 (LWP 9718)]
octave:3> graph = javaObject("Baz");
octave:4> graph.addNodes(1:1000000);

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
0x00007fffa6c706da in ?? ()
(gdb)


Adrian <adaerr>
Fri 27 Apr 2018 09:11:09 PM UTC, comment #32: 

When I run octave-cli from the Debian 4.2.2 on my system using gdb, I see this:


gdb --args octave-cli --norc
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave-cli...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/octave-cli --norc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2bae700 (LWP 32296)]
[New Thread 0x7fffe03ad700 (LWP 32297)]
[New Thread 0x7fffddbac700 (LWP 32298)]
[New Thread 0x7fffdb3ab700 (LWP 32299)]
[New Thread 0x7fffd8baa700 (LWP 32300)]
[New Thread 0x7fffd63a9700 (LWP 32301)]
[New Thread 0x7fffd3ba8700 (LWP 32302)]
GNU Octave, version 4.2.2
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> javaaddpath(".")

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
0x00007fffb475a4f3 in ?? ()
(gdb) imwrite(zeros(1000), "foo.png");
Undefined command: "imwrite".  Try "help".
(gdb) graph = javaObject("Baz");
Undefined command: "graph".  Try "help".
(gdb) graph.addNodes(1:1000000);
Undefined command: "graph".  Try "help".
(gdb) where
#0  0x00007fffb475a4f3 in ?? ()
#1  0x0000000000000206 in ?? ()
#2  0x00007fffb475a280 in ?? ()
#3  0x00007fffce76ff24 in Abstract_VM_Version::_vm_major_version () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
#4  0x00007fffffffb8d0 in ?? ()
#5  0x00007fffce23cf19 in VM_Version::get_processor_features() () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


When I compile and run the test program that I showed in comment #12 on the same system, I see


gdb ./a.out
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/jwe/a.out
/home/jwe/a.out: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
[Inferior 1 (process 32354) exited with code 0177]
(gdb) wherQuit
(gdb) quit
buserror:2195> LD_LIBRARY_PATH=/usr/lib/jvm/java-9-openjdk-amd64/lib/server gdb ./a.out
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/jwe/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdc00c4f3 in ?? ()
(gdb) where
#0  0x00007fffdc00c4f3 in ?? ()
#1  0x0000000000000202 in ?? ()
#2  0x00007fffdc00c280 in ?? ()
#3  0x00007ffff7d8df24 in Abstract_VM_Version::_vm_major_version () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
#4  0x00007fffffffdfe0 in ?? ()
#5  0x00007ffff785af19 in VM_Version::get_processor_features() () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


That appears to be exactly the same crash, independent of Octave.    Is the smaller test program incorrect?  If so, how should it be fixed?  If someone will show me how to make that program woek on my system with gdb, then maybe I could fix Octave as well.

Also, without gdb, the smaller test program appears to work properly.

Also, with valgrind --tool=memcheck --leak-check=full, I get the attached set of diagnostics.



(file #44046)

John W. Eaton <jwe>
Group administrator
Fri 27 Apr 2018 08:58:16 PM UTC, comment #31: 

I'm still not convinced that this isn't machine, kernel, and tool-dependent.  Even if the stand-alone program works on your machine, and octave-4.2.2 does not, that could be explained by the linker getting lucky with where it has put pages in memory.

I notice that you are using gdb version 7.12-6, while Dmitri is running 8.1-11.

@Dmitri: You reported that the test program worked for you.  Can you run a session of Octave under gdb and try the OP's test sequence


javaaddpath(".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
graph.addNodes(1:1000000);



Rik <rik5>
Group administrator
Fri 27 Apr 2018 08:55:29 PM UTC, comment #30: 

Using 4.2.2, does this test also fail with octave-cli running under gdb?

John W. Eaton <jwe>
Group administrator
Fri 27 Apr 2018 08:21:32 PM UTC, comment #29: 

I tested several combinations of octave and GNU/Linux kernel versions.
The TLDR; of this comment is that 4.0.3 runs the test fine on kernels
4.9 and 4.15, whereas 4.2.2 produces a segment violation error on all
tested kernels (4.9, 4.14 and 4.15). Combined with the previous
comment #28 this really points to a specific octave bug.

I ran

gdb --args octave --no-gui --norc

then typed 'run' to launch octave

then pasted line by line:


javaaddpath(".")
imwrite(zeros(1000), "foo.png");
graph = javaObject("Baz");
graph.addNodes(1:1000000);





Results

octave 4.0.3-3

GNU/Linux kernel 4.9.0-6-amd64 (Debian 4.9.82-1+deb9u3 (2018-03-02))
libc 2.24
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git

GNU/Linux kernel 4.15.0-3-amd64 (Debian 4.15.17-1 (2018-04-19))
libc 2.27
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git

No error/no segfault under gdb. Only error is from gdb openjdk plugin:


>> javaaddpath(".")
Installing openjdk unwinder
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in <module>
    class Types(object):
  File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
    nmethodp_t = gdb.lookup_type('nmethod').pointer()
gdb.error: No type named nmethod.


The other instruction execute fine.




octave 4.2.2

GNU/Linux kernel 4.9.0-6-amd64 (Debian 4.9.82-1+deb9u3 (2018-03-02))
libc 2.24
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git

under gdb:


octave:1> javaaddpath(".")
error: javaMethod: /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so: failed to load: /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so: cannot open shared object file: No such file or directory
error: called from
    javaaddpath at line 52 column 13


=> I guess this reflects a dependency problem in Debian:
octave 4.2.2 should depend on openjdk-9

once openjdk-9 is installed the 'javaaddpath(".")' instruction indeed passes without error. A segfault is produced by the last instruction 'graph.addNodes(1:1000000);'. Full log:


nyx:~/tmp/crashtest> gdb --args octave --no-gui --norc
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/octave --no-gui --norc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
process 9112 is executing new program: /usr/lib/x86_64-linux-gnu/octave/4.2.2/exec/x86_64-pc-linux-gnu/octave-gui
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdde4f700 (LWP 9116)]
[New Thread 0x7fffdd64e700 (LWP 9117)]
[New Thread 0x7fffd8e4d700 (LWP 9118)]
[New Thread 0x7fffd864c700 (LWP 9119)]
[New Thread 0x7fffd3e4b700 (LWP 9120)]
[New Thread 0x7fffd364a700 (LWP 9121)]
[New Thread 0x7fffcee49700 (LWP 9122)]
[New Thread 0x7fffcc648700 (LWP 9123)]
[New Thread 0x7fffc9e47700 (LWP 9124)]
[New Thread 0x7fffc9646700 (LWP 9125)]
[New Thread 0x7fffc4e45700 (LWP 9126)]
[New Thread 0x7fffc2644700 (LWP 9127)]
[New Thread 0x7fffbfe43700 (LWP 9128)]
[New Thread 0x7fffbd642700 (LWP 9129)]
[New Thread 0x7fffbae41700 (LWP 9130)]
[New Thread 0x7fffb2cd5700 (LWP 9131)]
[New Thread 0x7fffb1ead700 (LWP 9132)]
[New Thread 0x7fffb16ac700 (LWP 9133)]
GNU Octave, version 4.2.2
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.
top - 22:09:44 up 10:13,  5 users,  load average: 0.11, 0.14, 0.06
Tasks: 269 total,   1 running, 267 sleeping,   0 stopped,   0 zombie

octave:1> javaaddpath(".")
[New Thread 0x7fffb01c0700 (LWP 9134)]
[New Thread 0x7fff8a7ea700 (LWP 9135)]
[New Thread 0x7fff8a6e8700 (LWP 9136)]
[New Thread 0x7fff8a5e6700 (LWP 9137)]
[New Thread 0x7fff8a4e4700 (LWP 9138)]
[New Thread 0x7fff8a3e2700 (LWP 9139)]
[New Thread 0x7fff8a2e0700 (LWP 9140)]
[New Thread 0x7fff8a1de700 (LWP 9141)]
[New Thread 0x7fff8a0dc700 (LWP 9142)]
[New Thread 0x7fff89fda700 (LWP 9143)]
[New Thread 0x7fff89ed8700 (LWP 9144)]
[New Thread 0x7fff89dd6700 (LWP 9145)]
[New Thread 0x7fff89cd4700 (LWP 9146)]
[New Thread 0x7fff88ec5700 (LWP 9147)]
[New Thread 0x7fff88dc3700 (LWP 9148)]
[New Thread 0x7fff88cc1700 (LWP 9149)]
[New Thread 0x7fff88bbf700 (LWP 9150)]
[New Thread 0x7fff88abd700 (LWP 9151)]
[New Thread 0x7fff889bb700 (LWP 9152)]
[New Thread 0x7fff888b9700 (LWP 9153)]
[New Thread 0x7fff887b7700 (LWP 9154)]
[New Thread 0x7fff886b5700 (LWP 9155)]
[New Thread 0x7fff885b3700 (LWP 9156)]
[New Thread 0x7fff884b1700 (LWP 9157)]
[New Thread 0x7fff883af700 (LWP 9158)]
[New Thread 0x7fff882ad700 (LWP 9159)]
[New Thread 0x7fff881ab700 (LWP 9160)]
[New Thread 0x7fff15e57700 (LWP 9161)]
[New Thread 0x7fff15d55700 (LWP 9162)]
[New Thread 0x7fff15c53700 (LWP 9163)]
[New Thread 0x7fff15b51700 (LWP 9164)]
[New Thread 0x7fff144cc700 (LWP 9165)]
[New Thread 0x7fff143ca700 (LWP 9166)]
[New Thread 0x7fff142c9700 (LWP 9167)]
[New Thread 0x7fff141c8700 (LWP 9168)]
[New Thread 0x7fff05fff700 (LWP 9169)]
[New Thread 0x7fff05efe700 (LWP 9170)]
[New Thread 0x7fff05dfd700 (LWP 9171)]
[New Thread 0x7fff05cfc700 (LWP 9172)]
[New Thread 0x7fff05bfb700 (LWP 9173)]
[New Thread 0x7fff05afa700 (LWP 9174)]
[New Thread 0x7fff059f9700 (LWP 9175)]
[New Thread 0x7fff058f8700 (LWP 9176)]
[New Thread 0x7fff057f7700 (LWP 9177)]
[New Thread 0x7fff056f6700 (LWP 9178)]
[New Thread 0x7fff055f5700 (LWP 9179)]
[New Thread 0x7fff054f4700 (LWP 9180)]
[New Thread 0x7fff053f3700 (LWP 9181)]
[New Thread 0x7fff04ec8700 (LWP 9182)]
[New Thread 0x7fff04dc7700 (LWP 9183)]
[New Thread 0x7fff04cc6700 (LWP 9184)]
octave:2> imwrite(zeros(1000), "foo.png");
[New Thread 0x7ffeb3675700 (LWP 9185)]
[New Thread 0x7ffeb2e74700 (LWP 9186)]
[New Thread 0x7ffeb2673700 (LWP 9187)]
[New Thread 0x7ffeb1e72700 (LWP 9188)]
[New Thread 0x7ffeb1671700 (LWP 9189)]
[New Thread 0x7ffeb0e70700 (LWP 9190)]
[New Thread 0x7ffeabfff700 (LWP 9191)]
[New Thread 0x7ffeab7fe700 (LWP 9192)]
[New Thread 0x7ffeaaffd700 (LWP 9193)]
[New Thread 0x7ffeaa7fc700 (LWP 9194)]
[New Thread 0x7ffea9ffb700 (LWP 9195)]
[New Thread 0x7ffea97fa700 (LWP 9196)]
[New Thread 0x7ffea8ff9700 (LWP 9197)]
[New Thread 0x7ffea87f8700 (LWP 9198)]
[New Thread 0x7ffea7ff7700 (LWP 9199)]
octave:3> graph = javaObject("Baz");
octave:4> graph.addNodes(1:1000000);

Thread 18 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb1ead700 (LWP 9132)]
0x00007fff923936da in ?? ()
(gdb)


This being the stock octave from Debian without symbols, the backtrace is useless.

p.s.

The 4.0.9 kernel was a fresh Debian stretch/stable install, where octave is at 4.0.3. Octave 4.2.2 and openjdk-9 where then added by adding the buster/testing sources to apt.

Conversely, the 4.14/4.15 kernel was a testing system with octave at 4.2.2, then downgraded to 4.0.3 to test this combination also.

Adrian <adaerr>
Fri 27 Apr 2018 10:49:56 AM UTC, comment #28: 

Just as Dmitri in comment #20, the standalone JNI createJavaVM test program from comment #12 runs fine for me, in gdb or not, while on the same machine the original bug creates a segfault under gdb at the graph.addNodes instruction.

The standalone program works both with openjdk-8 and openjdk-9 (minor difference: error during plugin loading in gdb for openjdk-8, see below).

Here are the details on the test conditions:

GNU/Linux kernel 4.15.0-3-amd64 (Debian 4.15.17-1 (2018-04-19))
libc 2.27
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git

(side-note: the openjdk-8 test runs fine - with the same gdb.error for the plugin - also on a fresh Debian stable install with kernel 4.9; openjdk-9 is not packaged for stable yet)


openjdk-8:


$> g++ -ggdb3 -I/usr/lib/jvm/java-8-openjdk-amd64/include -I/usr/lib/jvm/java-8-openjdk-amd64/include/linux jni_createVM_test.c -L/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server -ljvm -o jni_createVM_test_openjdk-8
$> LD_LIBRARY_PATH=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server gdb ./jni_createVM_test_openjdk-8
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
[snip]
(gdb) run
Starting program: /home/adrian/tmp/crashtest/jni_createVM_test_openjdk-8
Installing openjdk unwinder
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in <module>
    class Types(object):
  File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
    nmethodp_t = gdb.lookup_type('nmethod').pointer()
gdb.error: No type named nmethod.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7fc6700 (LWP 6565)]
[snip]
[New Thread 0x7fffcf3f3700 (LWP 6595)]
VM = 0x7ffff7d8ef20
[Thread 0x7fffcf3f3700 (LWP 6595) exited]
[snip]
[Thread 0x7ffff7fc7740 (LWP 6561) exited]
[Inferior 1 (process 6561) exited normally]
(gdb) quit
$>LD_LIBRARY_PATH=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server ./jni_createVM_test_openjdk-8
VM = 0x7f3687891f20
$>


openjdk-9:


$> g++ -ggdb3 -I/usr/lib/jvm/java-9-openjdk-amd64/include -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux jni_createVM_test.c -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm -o jni_createVM_test_openjdk-9
$> LD_LIBRARY_PATH=/usr/lib/jvm/java-9-openjdk-amd64/lib/server gdb ./jni_createVM_test_openjdk-9
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
[snip]
Reading symbols from jni_createVM_test_openjdk-9...done.
(gdb) run
Starting program: /home/adrian/tmp/crashtest/jni_createVM_test_openjdk-9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdbf22700 (LWP 6644)]
[snip]
[New Thread 0x7fff560d5700 (LWP 6694)]
VM = 0x7ffff7d6ad40
[Thread 0x7fff560d5700 (LWP 6694) exited]
[snip]
[Thread 0x7ffff7fc7740 (LWP 6640) exited]
[Inferior 1 (process 6640) exited normally]
(gdb) quit
$> LD_LIBRARY_PATH=/usr/lib/jvm/java-9-openjdk-amd64/lib/server ./jni_createVM_test_openjdk-9
VM = 0x7f1921ba0d40
$>



Adrian <adaerr>
Wed 25 Apr 2018 03:56:41 PM UTC, comment #27: 

Not sure if this is relevant, just FYI -- here is the Fedora's hotspot patch added to 9.0.4.11

Dmitri.
--


(file #44031)

Dmitri A. Sergatskov <dasergatskov>
Wed 25 Apr 2018 03:16:40 PM UTC, comment #26: 

I agree.  Whatever this is, it is probably upstream and shouldn't delay the 4.4.0 release.

Rik <rik5>
Group administrator
Wed 25 Apr 2018 03:04:13 PM UTC, comment #25: 

Unless someone can show a way to make the standalone program work with gdb or asan, then I have to assume this bug is not a bug in Octave and there's not much we can do about it.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 10:43:39 PM UTC, comment #24: 

I ran the trivial program from comment #12 under valgrind, and it produces a lot of warnings about invalid writes.  I can't say how much of it is real, but the log file is attached.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 10:31:12 PM UTC, comment #23: 

Linux td-119156 4.16.3-300.fc28.x86_64 #1 SMP Thu Apr 19 19:04:56 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


BTW, this is may be of some interest:

https://bugzilla.redhat.com/show_bug.cgi?id=1492175

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 24 Apr 2018 10:30:40 PM UTC, comment #22: 

If this is a kernel problem, or a problem with the particular way that the address sanitizer and gdb work, would going back and trying valgrind be a solution?  From what I remember, that runs the executable in simulation, which is slow, but it doesn't depend on setting magic bits on memory pages and having the kernel and CPU detect triggering conditions.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 10:28:11 PM UTC, comment #21: 

@Dmitri: what does running 'uname -a' from the shell report?


Rik <rik5>
Group administrator
Tue 24 Apr 2018 10:18:05 PM UTC, comment #20: 

It seems the test program works for me -- no crash:


g++ -ggdb3 -I/usr/lib/jvm/java-9/include -I/usr/lib/jvm/jre-9/include/linux tjava.cc -L/usr/lib/jvm/java-9-openjdk/lib/server -ljvm

LD_LIBRARY_PATH=/usr/lib/jvm/java-9/lib/server ./a.out
VM = 0x7f726b71ed20

LD_LIBRARY_PATH=/usr/lib/jvm/java-9/lib/server gdb ./a.out
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) r
Starting program: /d2/home/dima/scratch/java/a.out
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-8.fc28.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Loadable section ".note.gnu.property" outside of ELF segments
[New Thread 0x7fffdc51e700 (LWP 14411)]
[New Thread 0x7fffdc41c700 (LWP 14412)]
[New Thread 0x7fffdc31a700 (LWP 14413)]
[New Thread 0x7fffdc218700 (LWP 14414)]
[New Thread 0x7fffcfcfc700 (LWP 14415)]
[New Thread 0x7fffcfbfa700 (LWP 14416)]
[New Thread 0x7fffcfaf8700 (LWP 14417)]
[New Thread 0x7fffcf9f6700 (LWP 14418)]
[New Thread 0x7fffcf8f4700 (LWP 14419)]
[New Thread 0x7fffcc69c700 (LWP 14420)]
[New Thread 0x7fffcc59a700 (LWP 14421)]
[New Thread 0x7fffa83af700 (LWP 14422)]
[New Thread 0x7fffa82ad700 (LWP 14423)]
[New Thread 0x7fffa81ac700 (LWP 14424)]
[New Thread 0x7fffa17ff700 (LWP 14425)]
[New Thread 0x7fffa16fe700 (LWP 14426)]
[New Thread 0x7fffa15fd700 (LWP 14427)]
[New Thread 0x7fffa14fc700 (LWP 14428)]
[New Thread 0x7fffa13fb700 (LWP 14429)]
[New Thread 0x7fffa0ed0700 (LWP 14430)]
[New Thread 0x7fffa0dcf700 (LWP 14431)]
[New Thread 0x7fffa0cce700 (LWP 14432)]
VM = 0x7ffff7d69d20
[Thread 0x7fffa0ed0700 (LWP 14430) exited]
[Thread 0x7fffa13fb700 (LWP 14429) exited]
[Thread 0x7fffa14fc700 (LWP 14428) exited]
[Thread 0x7fffa15fd700 (LWP 14427) exited]
[Thread 0x7fffa16fe700 (LWP 14426) exited]
[Thread 0x7fffa17ff700 (LWP 14425) exited]
[Thread 0x7fffa81ac700 (LWP 14424) exited]
[Thread 0x7fffa82ad700 (LWP 14423) exited]
[Thread 0x7fffa83af700 (LWP 14422) exited]
[Thread 0x7fffcc59a700 (LWP 14421) exited]
[Thread 0x7fffcc69c700 (LWP 14420) exited]
[Thread 0x7fffcf8f4700 (LWP 14419) exited]
[Thread 0x7fffcf9f6700 (LWP 14418) exited]
[Thread 0x7fffcfaf8700 (LWP 14417) exited]
[Thread 0x7fffcfbfa700 (LWP 14416) exited]
[Thread 0x7fffcfcfc700 (LWP 14415) exited]
[Thread 0x7fffdc218700 (LWP 14414) exited]
[Thread 0x7fffdc31a700 (LWP 14413) exited]
[Thread 0x7fffdc41c700 (LWP 14412) exited]
[Thread 0x7fffdc51e700 (LWP 14411) exited]
[Thread 0x7ffff7fbe740 (LWP 14400) exited]
[Thread 0x7fffa0dcf700 (LWP 14431) exited]
[Inferior 1 (process 14400) exited normally]
Missing separate debuginfos, use: dnf debuginfo-install java-9-openjdk-headless-9.0.4.11-6.fc28.x86_64 libgcc-8.0.1-0.20.fc28.x86_64 libstdc++-8.0.1-0.20.fc28.x86_64 zlib-1.2.11-7.fc28.x86_64
(gdb)


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 24 Apr 2018 10:10:28 PM UTC, comment #19: 

I compiled the test case from comment #12 and it segfaults as well when using ASAN.  If this is a kernel issue, it seems to affect multiple kernels.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 09:58:26 PM UTC, comment #18: 

After compiling with ASAN and trying "__java_init__" I get


octave:1> __java_init__
ASAN:SIGSEGV
=================================================================
==23466==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f5168c262b4 bp 0x7f51791d92a0 sp 0x7f517ac8c478 T3)
    #0 0x7f5168c262b3  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
Thread T3 (QThread) created by T0 here:
    #0 0x7f51a5d5f253 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x36253)
    #1 0x7f519edd8d58 in QThread::start(QThread::Priority) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0xacd58)

==23466==ABORTING



Rik <rik5>
Group administrator
Tue 24 Apr 2018 09:45:38 PM UTC, comment #17: 

The bug I referenced

https://bugs.openjdk.java.net/browse/JDK-8183188

points to

https://access.redhat.com/security/vulnerabilities/stackguard?sc_cid=70160000000gzltAAA&

I think ASAN uses stack guard pages also.  Does gdb?  Is that what causes the program to crash when running in those environments?

The OP mentioned that the problem appears on some systems an not others.  Could that be due to differences in kernel versions?

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 09:34:25 PM UTC, comment #16: 

I just noticed the same thing


/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py


Given that the backtrace contains


Python Exception <class 'OverflowError'> int too big to convert:


maybe this is something related to this plugin interface.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 09:32:11 PM UTC, comment #15: 

Another possibility would be to compile with ASAN.  I found that with the address sanitizer installed I got a quick segfault.  I'm going to try building without debugging, but with ASAN, so that gdb is not involved.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 09:28:33 PM UTC, comment #14: 


set auto-load python-scripts off
...
info auto-load


?

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 09:21:31 PM UTC, comment #13: 

Is it possible that gdb is interacting with the JVM in some way to produce this segfault that is not a real symptom? On my system, there are gdb plugins under /usr/share/gdb for each of the versions of libjvm.so that are installed on my system:


$ find /usr/share/gdb | grep java
/usr/share/gdb/auto-load/usr/lib/jvm/java-11-openjdk-amd64
/usr/share/gdb/auto-load/usr/lib/jvm/java-11-openjdk-amd64/jre
/usr/share/gdb/auto-load/usr/lib/jvm/java-11-openjdk-amd64/jre/lib
/usr/share/gdb/auto-load/usr/lib/jvm/java-11-openjdk-amd64/jre/lib/server
/usr/share/gdb/auto-load/usr/lib/jvm/java-11-openjdk-amd64/jre/lib/server/libjvm.so-gdb.py
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server
/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py
/usr/share/gdb/auto-load/usr/lib/jvm/java-10-openjdk-amd64
/usr/share/gdb/auto-load/usr/lib/jvm/java-10-openjdk-amd64/jre
/usr/share/gdb/auto-load/usr/lib/jvm/java-10-openjdk-amd64/jre/lib
/usr/share/gdb/auto-load/usr/lib/jvm/java-10-openjdk-amd64/jre/lib/server
/usr/share/gdb/auto-load/usr/lib/jvm/java-10-openjdk-amd64/jre/lib/server/libjvm.so-gdb.py
/usr/share/gdb/auto-load/usr/lib/jvm/java-9-openjdk-amd64
/usr/share/gdb/auto-load/usr/lib/jvm/java-9-openjdk-amd64/jre
/usr/share/gdb/auto-load/usr/lib/jvm/java-9-openjdk-amd64/jre/lib
/usr/share/gdb/auto-load/usr/lib/jvm/java-9-openjdk-amd64/jre/lib/server
/usr/share/gdb/auto-load/usr/lib/jvm/java-9-openjdk-amd64/jre/lib/server/libjvm.so-gdb.py


Is there a way to prevent these plugins from being loaded to see whether the segfault occurs when gdb is not trying to load the JVM independently of Octave trying to load it?

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 09:14:42 PM UTC, comment #12: 

It crashes for you inside the dlopen call?  That's weird.  For me, it crashes inside the call to the create vm function.

This problem appears to be independent of Octave.

Try the following program:


#include <jni.h>
#include <stdlib.h>

int
main (void)
{
  JavaVMInitArgs vmArgs = { 0 };

  vmArgs.version = JNI_VERSION_1_8;
  vmArgs.nOptions = 0;
  vmArgs.ignoreUnrecognized = false;

  JNIEnv *env = NULL;
  JavaVM *jvm = NULL;

  jint ret = JNI_CreateJavaVM (&jvm, (void **) &env, &vmArgs);
  if (ret < 0 || jvm == NULL)
    {
      printf ("failed\n");
      //log(0, "Unable to create a Java Virtual Machine");
      return -1;
    }

  printf ("VM = %p\n", jvm);

  return 0;
}


Note that this doesn't use dlopen/dlsym.  On my system, I compile with


g++ -ggdb3 -I/usr/lib/jvm/java-9-openjdk-amd64/include -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux java-example.c -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm


Your include file and library directories may be different.

Then if I run it with


$ LD_LIBRARY_PATH=/usr/lib/jvm/java-9-openjdk-amd64/lib/server ./a.out
VM = 0x7f2c09809d40


it appears to succeed and prints the address of the JVM object created by JNI_CreateJavaVM.

However, if I run it with gdb, it segfaults in the same way as I am seeing with Octave:


$ LD_LIBRARY_PATH=/usr/lib/jvm/java-9-openjdk-amd64/lib/server gdb ./a.out
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) r
Starting program: /home/jwe/code-snippets/2/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffdc00c4f3 in ?? ()
(gdb) where
#0  0x00007fffdc00c4f3 in ?? ()
#1  0x0000000000000206 in ?? ()
#2  0x00007fffdc00c280 in ?? ()
#3  0x00007ffff7d8df24 in Abstract_VM_Version::_vm_major_version () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
#4  0x00007fffffffdfd0 in ?? ()
#5  0x00007ffff785af19 in VM_Version::get_processor_features() () from /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


I found this example here:  https://bugs.openjdk.java.net/browse/JDK-8183188

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 08:59:14 PM UTC, comment #11: 

I stepped through all the way through and the issue occurs for me in the dlopen call at line 208 of oct-shlib.cc


  library = dlopen (file.c_str (), flags);


The variable file holds


"/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so"


I tried changing the flags sent to dlopen, but that didn't help either.  This bug may be upstream in libjvm itself.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 08:12:26 PM UTC, comment #10: 

Stepping through the code in initialize_jvm


  JNIEnv *current_env;
  const char *static_locale = setlocale (LC_ALL, nullptr);
  const std::string locale (static_locale);

  octave::dynamic_library lib ("");
  std::string jvm_lib_path = "linked in or loaded libraries";

  // Check whether the Java VM library is already loaded or linked in.
  JNI_CreateJavaVM_t create_vm = reinterpret_cast<JNI_CreateJavaVM_t>
                                 (lib.search ("JNI_CreateJavaVM"));
  JNI_GetCreatedJavaVMs_t get_vm = reinterpret_cast<JNI_GetCreatedJavaVMs_t>
                                   (lib.search ("JNI_GetCreatedJavaVMs"));

  if (! create_vm || ! get_vm)
    {


I checked and both create_vm and get_vm are 0 so this branch is taken.

The code then jumps down to this


#else
      // JAVA_LDPATH determined by configure and set in config.h
#  if defined (__APPLE__)
      jvm_lib_path = JAVA_LDPATH + std::string ("/libjvm.dylib");
#  else
      jvm_lib_path = JAVA_LDPATH + std::string ("/libjvm.so");
#  endif
#endif
      lib = octave::dynamic_library (jvm_lib_path);


For a Linux system, the path ends in libjvm.so.  Finally, the segfault occurs in the next line.

Maybe something bad happens when we call the constructor with a null value?


  octave::dynamic_library lib ("");


Or maybe when lib.search fails it leaves the object lib in a bad state?


Rik <rik5>
Group administrator
Tue 24 Apr 2018 08:02:44 PM UTC, comment #9: 

As you will have discovered, you can use the internal function _java_init_ just to start the JVM.  That might help with debugging.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 07:05:57 PM UTC, comment #8: 

I'm looking at this now.  The failure is inside the JVM JNI_CreateJavaVM function.  Maybe we are calling it incorrectly or not managing the memory for the arguments properly.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 06:54:07 PM UTC, comment #7: 

There is another bug report about lint warnings during compilation of Octave's own java library.


Note: org/octave/ClassHelper.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.


Maybe it is a red herring, but unchecked, unsafe accesses to memory could certainly produce a segfault.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 06:13:45 PM UTC, comment #6: 

Under gdb I can confirm a SEGFAULT.  I used


./run-octave -f


and then attached to the running process with 'gdb -p XXXX'.  Within Octave, I ran


javaaddpath ('.')


Note, I didn't even need to call javaObject.

The backtrace is pretty useless



Installing openjdk unwinder

Thread 4 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff269261700 (LWP 24191)]
0x00007ff24d0002b4 in ?? ()
(gdb) bt
#0  0x00007ff24d0002b4 in  ()
#1  0x49656e696c65746e in  ()
#2  0x01100800000406e3 in  ()
Python Exception <class 'OverflowError'> int too big to convert:
#3  0xbfebfbff7ffafbbf in  ()#4  0x01c0003f1c004121 in  ()
#5  0x000000000000003f in  ()
#6  0x0000000000000000 in  ()


This was with the release candidate 4.3.91.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 10:30:15 AM UTC, comment #5: 

@Dimitri/comment #4: The ClassNotFoundException seems to indicate
that the class is not instantiated, maybe that is why you see no
segfault (running under gdb I suppose). Do you have Baz.class in
the pwd ?

@Mike/comment #3: Thanks for further narrowing things down. So if
I understand correctly loading the class alone already causes
some bad memory accesses, and the other instructions were just
necessary to reveal the memory corruption when run outside gdb ? That
would explain why this bug for a long time seemed almost non
reproducible to me, striking unexpectedly at different moments
when working interactively.

Just to be sure: you remove the octave-workspace before running
your minimal example ? I found that the presence of a workspace
resulting from a previous crash can change the point at which the
segmentation fault hits (my first attempt at a minimal example
did not crash anymore once I had removed the workspace).

Sorry for the confusion regarding the image package, somehow I
thought it provided imwrite, I should have checked.

Adrian <adaerr>
Tue 24 Apr 2018 12:05:39 AM UTC, comment #4: 

hg id faed660f7222 seems to work on Fedora:


octave:1> javaaddpath (".")
octave:2> graph = javaObject ("Baz");
error: [java] java.lang.ClassNotFoundException: Baz
octave:2> __octave_config_info__ ("hg_id")
ans = faed660f7222
octave:3> __octave_config_info__ ("config_opts")
ans =  'JAVA_HOME=/usr/lib/jvm/java-9'


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 23 Apr 2018 11:36:58 PM UTC, comment #3: 

I can reproduce this crash with Octave 4.2.2 and Octave 4.3.91, both are linked with OpenJDK 9, including the Debian package octave 4.2.2-2.

I have a self-compiled Octave 4.2.2 that is linked with OpenJDK 8. It does not immediately appear to crash in the same way. But when I run it under gdb, it does generate a segmentation fault.

The image package is not needed at all to reproduce this error. The imwrite function is part of Octave, no packages or init files are needed.

In fact the call to 'imwrite' is not needed at all either. When it is not present, octave appears to run and exit normally, but under gdb the segmentation fault can still be seen. The minimal example


javaaddpath (".")
graph = javaObject ("Baz");


still generates a segmentation fault when run under gdb.

Mike Miller <mtmiller>
Group Member
Mon 23 Apr 2018 11:00:25 PM UTC, comment #2: 

Also forgot references to bugs #52501, #50644 and #50068 that seem to reflect the case of the "immune computer" described in the original submission. That "panic: Aborted" error is however different from the segmentation fault reported here.

Adrian <adaerr>
Mon 23 Apr 2018 10:45:17 PM UTC, comment #1: 

Forgot to add that I did take care of moving the .octaverc out of the way. The segmentation fault remains when specifying --no-init-file --no-site-file

Adrian <adaerr>
Mon 23 Apr 2018 10:38:07 PM UTC, original submission:  

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.

Adrian <adaerr>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #44046:  java-example.log added by jwe (878KiB - text/x-log)
file #44031:  PStack-808293.patch added by dasergatskov (2KiB - text/x-patch)
file #44013:  val.log.lz added by rik5 (20KiB - application/x-lzip)
file #44000:  crashtest.m added by adaerr (121B - text/x-objcsrc)
file #44001:  Baz.java added by adaerr (91B - text/x-java)
file #44002:  Baz.class added by adaerr (240B - application/java-vm)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by adaerr (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-23 mtmiller Carbon-CopyRemoved 80942 -
    2018-05-01 mtmiller Release4.3.91 4.4.0
    2018-04-27 jwe Attached File- Added java-example.log, #44046
    2018-04-25 dasergatskov Attached File- Added PStack-808293.patch, #44031
    2018-04-24 rik5 Attached File- Added val.log.lz, #44013
    2018-04-24 rik5 Release4.2.2 4.3.91
    2018-04-23 mtmiller CategoryNone Libraries
        StatusNone Confirmed
    2018-04-23 adaerr Attached File- Added crashtest.m, #44000
        Attached File- Added Baz.java, #44001
        Attached File- Added Baz.class, #44002

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code