Thu 21 May 2015 04:44:33 AM UTC, comment #29:
If this is just a problem with the run-octave script, and it works once it is installed, then I'm inclined to move on and close this report.
|
Wed 20 May 2015 04:14:01 PM UTC, comment #28:
When i run the tests with the installed octave
The result of running the three tests was ok.
------------------------------------------------------------
>> test tst1
PASSES 47 out of 47 tests
>> test tst2
PASSES 2 out of 2 tests
>> test tst3
PASSES 1 out of 1 test
>>
-------------------------------------------------------------
When I ran the same version of octave from the build directory with ./run-octave
tests 2 and 3 fail with segfault as before.
best
joaquin
|
Mon 18 May 2015 10:49:57 PM UTC, comment #27:
Using current stable and Fedora 21 all three
tests pass.
|
Sun 17 May 2015 11:51:21 PM UTC, comment #26:
Addendum to last comment, to run
|
Sun 17 May 2015 11:50:24 PM UTC, comment #25:
I've broken up the tests in ov-class.cc-tst in to three files which are attached. Can you run the tests individually from the command line? I expect that the first two will pass and that the third will cause the segfault.
(file #34040, file #34041, file #34042)
|
Thu 30 Apr 2015 08:03:16 PM UTC, comment #24:
Hi run as you said with the same build as before :
"octave:1> test libinterp/octave-value//ov-class.cc-tst
Program received signal SIGSEGV, Segmentation fault.
0x00007fffd11c42b4 in ?? ()
(gdb) bt
#0 0x00007fffd11c42b4 in ?? ()
#1 0x0000000000000246 in ?? ()
#2 0x00007fffd11c4160 in ?? ()
#3 0x00007fffe179d470 in VM_Operation::_names ()
from /usr/lib/jvm/jdk1.8.0_45/jre/lib/amd64/server/libjvm.so
#4 0x00007fffffff7060 in ?? ()
#5 0x00007fffe12d4f6d in VM_Version::get_processor_features() ()
from /usr/lib/jvm/jdk1.8.0_45/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
"
regards,
joaquin
|
Thu 30 Apr 2015 04:13:29 PM UTC, comment #23:
Re-opening this bug report since it is evidently still reproducible.
Could the original reporter run the following:
I want to confirm that the problem is solely an interaction between the JVM and Octave's class files. The other possibility is that there has been a memory leak in some of the previous tests executed by make check which is only later resulting in a segfault.
|
Tue 28 Apr 2015 09:33:34 PM UTC, comment #22:
I am the original poster .
today 28-04-2015 i built again from mercurial to see if i could get different results:
changeset: 20139:bcf0a288aa6c
branch: stable
tag: tip
parent: 19858:77f65eabac20
parent: 20138:4ff975c58584
user: John W. Eaton <jwe@octave.org>
date: Tue Apr 28 12:12:16 2015 -0400
summary: maint: Merge default to stable in preparation for 4.0.0 release.
Previously I had cleaned the java installation on my ubuntu 14.04
amd64 (I keep my installation always up to date).
Tried with the default openjdk 1.7 but got the same problem
as reported here the only difference was that gdb report wasn't very much detailed.
So I went back to oracle java jdk 1.8.0 (now 1.8.0_45)
I have got the same segfault as before (compilation goes right
to the end but make check doesn't )
partial output from gdb :
------------------------------------------------------------
build/libinterp/dldfcn/fftw.cc-tst .......................... PASS 13/13
build/libinterp/dldfcn/qr.cc-tst ............................ PASS 48/48
build/libinterp/octave-value/ov-base.cc-tst ................. PASS 1/1
build/libinterp/octave-value/ov-bool-mat.cc-tst ............. PASS 1/1
build/libinterp/octave-value/ov-cell.cc-tst ................. PASS 1/1
build/libinterp/octave-value/ov-class.cc-tst ................
Program received signal SIGSEGV, Segmentation fault.
0x00002aaae80002b4 in ?? ()
(gdb) where
#0 0x00002aaae80002b4 in ?? ()
#1 0x0000000000000246 in ?? ()
#2 0x00002aaae8000160 in ?? ()
#3 0x00002aaadcf83470 in VM_Operation::_names ()
from /usr/lib/jvm/jdk1.8.0_45/jre/lib/amd64/server/libjvm.so
#4 0x00007fffffff3890 in ?? ()
#5 0x00002aaadcabaf6d in VM_Version::get_processor_features() ()
from /usr/lib/jvm/jdk1.8.0_45/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
---------------------------------------------------------------
In the meantime between my previous post and this one
i tried with openjd 1.8 with the same problem.
regards
joaquin
|
Sun 08 Mar 2015 05:49:25 PM UTC, comment #21:
Can the original reporter post what version of a Java JDK they were using and who made it? If it is a propietary version, could they try temporarily installing a different java virtual machine, such as the one from OpenJDK, and see if it works?
|
Sun 08 Mar 2015 12:56:27 PM UTC, comment #20:
Rik: Yes I ran a full 'make check', zero failures and no segfaults. But no, it is not the same Java as the reporter. The reporter was likely using Oracle JDK judging by the naming scheme, while mine is Debian packaged OpenJDK.
|
Sun 08 Mar 2015 12:11:15 PM UTC, comment #19:
@Mike: Did you run the full 'make check' or just 'test ov-class.cc'?
In the original reporter's (OR) log from 'make check' there were some scary looking warnings resulting from the audiodev tests. It might be that the memory overrun started there and then was only exposed later. If that is the case then 'test ov-class.cc' won't be enough to expose the bug.
Also, the OR was using version jdk1.8.0_31. Was this the same in your test?
|
Sun 08 Mar 2015 03:39:33 AM UTC, comment #18:
Just did a test build using OpenJDK 8, no segfault and no test failures here.
|
Sat 07 Mar 2015 11:41:15 PM UTC, comment #17:
Both gdb backtraces show errors occuring inside of Oracle Java 8. Can you test Octave built with --disable-java and see if the same crash occurs? As Rik said, we don't know that anyone has tried building Octave with a Java 8 version yet.
|
Sun 01 Mar 2015 04:52:27 AM UTC, comment #16:
Re-titling report. None of the gdb backtraces show a problem with _osmesa_print_.cc. Rather it is tests in ov-class.cc that are the issue.
In terms of testing, since the original reporter is running from Mercurial sources it will be faster to run the individual failing tests, rather than running 'make check'. The following should do this
I assume this will fail. But if it doesn't, then we probably need to look at the other test failures with the audio tests.
One thing I notice is that the backtrace suggests a Java SE 8 virtual machine. Almost all of the testing to date has been with Java SE 7. Who knows whether this important, but the Wikipedia entry for SE 8 says that there are now statically linked JNI libraries. That might affect Octave.
|
Sat 28 Feb 2015 04:47:47 PM UTC, comment #15:
Hello with changeset: 19876:f799bf70350f
I get almost the same reult with the debugger.
file attached.
regards
joaquin
(file #33211)
|
Sat 28 Feb 2015 04:35:01 PM UTC, comment #14:
This bug may still be present, as there could be multiple bugs in that area of the code, one of which may have been found, as noted. However, even after a couple revs of fixing that bug, I'm still seeing Qt plotting problems.
This bug report
https://savannah.gnu.org/bugs/?44330
could be related to the same bug (or bugs).
It seems putting Qt into non-visible mode is an issue, as well as closing and reopening a figure under Qt toolkit. (See above bug report for samples.)
|
Sat 28 Feb 2015 12:35:30 AM UTC, comment #13:
I believe this may have been fixed in this cset 6b7aee95c54c from today (2/27/15). Could the original reporter pull the latest from Mercurial and try again.
|
Fri 27 Feb 2015 06:08:51 PM UTC, comment #12:
This seems very likely due to an incorrect std::string::find call that was corrected in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/ed5ee3f610db).
At this point, running 'test _osmesa_print_' fails outright, but does not cause a segfault.
|
Thu 26 Feb 2015 05:32:44 PM UTC, comment #11:
In terms of debugging, it would also be nice if you could start back at the most vanilla configuration/make environment possible and then slowly add options until one of them breaks things.
In this case, could you run just
rather than giving CFLAGS and CXXFLAGS options? I know of at least one test for log2 which does fail when Octave is built with '-O0' and maybe there is something similar here. If you run with the default options then you will be getting '-O2'.
|
Thu 26 Feb 2015 05:18:37 PM UTC, comment #10:
It appears to be crashing inside the JVM, not inside an Octave function. If we are using the JVM incorrectly then maybe there is something to fix. Or it's possible that this some other configuration problem that is specific to your system.
|
Wed 25 Feb 2015 09:53:32 PM UTC, comment #9:
Hello,
Sorry about last post, hope now the output of gdb helps
file attached
regards,
joaquin
(file #33187)
|
Wed 25 Feb 2015 05:39:59 PM UTC, comment #8:
At this point, you need to type "where" at the "(gdb)" prompt to get some more information about where the crash is happening.
|
Wed 25 Feb 2015 11:39:12 AM UTC, comment #7:
Hello
with hg head changeset: 19857:bf511802add7
run :
make check RUN_OCTAVE_OPTIONS="-g --no-gui-libs"
partial output in attached file.
regards
joaqin
(file #33181)
|
Wed 25 Feb 2015 02:32:47 AM UTC, comment #6:
If the test suite does not need to be run with Qt enabled, this works for me:
|
Wed 25 Feb 2015 02:11:34 AM UTC, comment #5:
Currently, it's a little complicated to run the test suite with the debugger. Here's one way:
Start octave.
Evaluate the following command to start gdb on the Octave process:
When gdb starts and presents the "(gdb) " prompt, type c to continue.
At the Octave prompt, cd to your the test directory in your Octave source tree and execute the "fntests" script.
I'm thinking about ways to make this simpler so that it can work from a Makefile target...
|
Wed 25 Feb 2015 01:39:03 AM UTC, comment #4:
Can you run make check in gdb and provide a stacktrace at the point of the segfault?
|
Wed 25 Feb 2015 12:20:24 AM UTC, comment #3:
Sorry built with :
../configure && make CFLAGS=-O CXXFLAGS=-O LDFLAGS= && make check
and got the same message as begore :
build/libinterp/dldfcn/__osmesa_print__.cc-tst ..............panic: Segmentation fault -- stopping myself...
octave exited with signal 11
Doesn't look like it's related to llvm
regards,
joaquin
|
Tue 24 Feb 2015 06:08:41 PM UTC, comment #2:
That reminds me of Debian bug #743260 (I don't remember if anyone ever reported it here). If your video driver happens to use one version of LLVM and Octave uses a different version of LLVM, yes Octave will definitely segfault when trying to plot anything.
|
Tue 24 Feb 2015 05:34:51 PM UTC, comment #1:
Could you try again without --enable-jit? I recently noticed a problem with Octave crashing while trying to plot (to the screen, not to a file) when I enabled jit. I did not have time to track down the problem, but if the problem also goes away for you if you use --disable-jit (the default) then at least that will be confirmation that there is some problem triggered by linking with LLVM libraries (my guess to the source of the problem).
You won't be missing anything by disabling the JIT compiler. It really doesn't do anything useful at this point.
|
Tue 24 Feb 2015 08:22:27 AM UTC, original submission:
Hello i built octave from mercurial on ubuntu 14.04 64 bits.
hg head :
changeset: 19842:03adada53347
the only option passed to configure was --enable-jit
build successful but tests failed with :
build/libinterp/dldfcn/__ilu__.cc-tst ....................... PASS 1/1
build/libinterp/dldfcn/__magick_read__.cc-tst ............... PASS 4/4
build/libinterp/dldfcn/__osmesa_print__.cc-tst ..............panic: Segmentation fault -- stopping myself...
octave exited with signal 11
I don't know if the problem is with the test or with octave
anyway i installed and seems ok although running the test
form the gui gives a segmentation fault (gui closes).
regards
joaquin
|