On 5/18/19 5:02 AM, idontgetoutmuch wrote:
I am trying to use chebfun (http://www.chebfun.org). I have
GNU Octave, version 5.1.0
[...]> octave:1> x = chebfun('x');
Illegal instruction: 4
Here's a bit more information:
Process: octave-gui [85121]
Path:
/usr/local/Cellar/octave/5.1.0_4/libexec/octave/5.1.0/exec/x86_64-apple-darwin17.7.0/octave-gui
Identifier: octave-gui
Version: 0
Code Type: X86-64 (Native)
Parent Process: bash [528]
Responsible: octave-gui [85121]
User ID: 501
Date/Time: 2019-05-18 09:59:18.450 +0100
OS Version: Mac OS X 10.13.2 (17C88)
[...]
I can reproduce this.
$ octave -q
octave:1> addpath ~/tmp/chebfun/chebfun-master
octave:2> x = chebfun('x')
[1] 734 illegal hardware instruction (core dumped) octave -q
[/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/Casks]
$ octave --version
GNU Octave, version 5.1.0
This is on macOS 10.14.5 on my Late 2015 iMac 5K. Happens with either
Octave.app 4.4.1 GUI, Octave.app 5.1.0 beta GUI, or Homebrew-installed
Octave 5.1.0_4 CLI.
Here's a crash dump:
https://github.com/octave-app/octave-app/files/3194133/octave-gui_2019-05-18-100317_angharad-running-chebfun.crash.zipNormally problems with libraries should be reported to the library
maintainers themselves, but since this is causing a low-level error like
an illegal instruction or other crash, that suggests that it's
encountering a bug in Octave itself.
idontgetoutmuch, what model of Mac are you using (type and release
year), so we can figure out what CPU model you have? That's often
relevant to Illegal Instruction errors; they usually mean that you're
running binary code that was compiled for a newer generation of CPU than
yours. Though it's somewhat surprising here: You have a
Homebrew-installed Octave, and Homebrew's bottle distribution has
binaries that are built for Core 2, for wide compatibility. And my iMac,
which is also getting an Illegal Instruction, has a quite new i7-6700K
Skylake CPU, so it should be able to run anything.
The zero-arg `chebfun()` constructor does not crash.
I threw it in the debugger.
Looks like it's happening at line 230 in @chebfun/chebfun.m, where it
does this:
f.pointValues = chebfun.getValuesAtBreakpoints(f.funs, ...
f.domain, op);
That `f.domain` _expression_ is resolving to the "domain" method defined
in @chebfun/domain.m. (I can tell because that's where I end up when I
do a `dbstep in` on that line.) The weird thing is that the @chebfun
class defines both a "domain" method (not "set.domain"/"get.domain"
accessors) and a "domain" property.
The domain method in turn is calling f.domain:
elseif ( numel(f) == 1 )
% CHEBFUN case:
A = f.domain;
Which seems like it's intended to get the property?
To be honest, I'm not sure what's supposed to happen in this case where
you have both a method and a property with the same name. (And the
method is not declared with a prototype in the classdef.) But I do know
that a crash is not the right behavior. :) I would think that, even
inside the class definition code, it would always resolve to one or the
other (since we're not dealing with subsref here), and it would either
always get the property directly, or it would turn into an infinite
recursion, since "f.domain" would mean a method call even inside the
domain() method definition. So I'm kind of surprised that this chebfun
code works under Matlab as is.
If I call `f.domain` interactively while stopped in the constructor in
the debugger, it also crashes Octave. So I suspect that's what's doing it.
I can reproduce the Illegal Instruction crash with this simple repro case:
$ cat Recurser.m
classdef Recurser
properties
domain
endproperties
methods
function out = domain(this)
out = this.domain;
endfunction
endmethods
endclassdef
[~/Documents/octave]
$ octave
octave:1> r = Recurser;
octave:2> r.domain
[1] 2292 illegal hardware instruction (core dumped) octave -q
[~/Documents/octave]
$
So, maybe what's happening is that the infinite-recursion case is
kicking in, and Octave doesn't handle that gracefully?
Cheers,
Andrew