[Top][All Lists]


Re: chebfun gives Illegal instruction: 4

From: dominic
Subject: Re: chebfun gives Illegal instruction: 4
Date: Sat, 18 May 2019 16:07:39 +0100

Thanks very much for taking a look at this (and in such depth). I did find this on the chebfun website: "No, Chebfun does not work in Octave, because it relies too intimately on the object-oriented features of MATLAB.” which I posted on #octave earlier (when I thought my email had not been received). But I agree it should not produce an illegal instruction.

I am sad that I can’t use chebfun but it is not essential to what I am doing.

Thanks once again.

Dominic Steinitz
Twitter: @idontgetoutmuch

On 18 May 2019, at 15:35, Andrew Janke <address@hidden> wrote:

On 5/18/19 5:02 AM, idontgetoutmuch wrote:
I am trying to use chebfun ( 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]
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
$ octave --version
GNU Octave, version 5.1.0

This is on macOS 10.14.5 on my Late 2015 iMac 5K. Happens with either 4.4.1 GUI, 5.1.0 beta GUI, or Homebrew-installed
Octave 5.1.0_4 CLI.

Here's a crash dump:

Normally 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
   function out = domain(this)
     out = this.domain;
$ octave
octave:1> r = Recurser;
octave:2> r.domain
[1]    2292 illegal hardware instruction (core dumped)  octave -q

So, maybe what's happening is that the infinite-recursion case is
kicking in, and Octave doesn't handle that gracefully?


reply via email to

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