bugGNU Octave - Bugs: bug #41213, JIT segfaults on non-x86 processors


bug #41213: JIT segfaults on non-x86 processors

Submitter:  Mike Miller <mtmiller>
Submitted:  Sun 12 Jan 2014 09:52:33 PM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  1 - Later Item Group:  Segfault, Bus Error, etc.
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 21 Dec 2021 08:52:13 AM UTC, comment #14: 

Indeed, closing as "Won't Fix"

Pantxo Diribarne <pantxo>
Project Member
Tue 21 Dec 2021 03:17:46 AM UTC, comment #13: 

Close this bug because no more JIT?

Thu 23 Jan 2014 04:44:09 PM UTC, comment #12: 

JIT is no longer compiled in by default (although still available for the brave on x86 platforms with --enable-jit).  I'm marking the bug as postponed since this likely won't see any attention until after the 4.0 GUI release.

Rik <rik5>
Project Administrator
Wed 15 Jan 2014 07:51:47 PM UTC, comment #11: 

The code that causes segfault on mingw (as descibed in bug #40608) runs fine with armel.

PS: Builing octave on armel with qemu-system-arm is very easy, but it tooks almost 2 days. :)

Stefan Mahr <dac922>
Mon 13 Jan 2014 10:29:29 PM UTC, comment #10: 

Note that _run_test_suite_ on Windows/mingw (x86 & x86_64) also segfaults (after a long wait, seemingly like hanging)

I reported this earlier (bug #40608)

Philip Nienhuis <philipnienhuis>
Project Member
Mon 13 Jan 2014 06:50:24 PM UTC, comment #9: 

I agree, this is probably the safest and most consistent approach to take for the time being.

Mike Miller <mtmiller>
Project Administrator
Mon 13 Jan 2014 06:32:36 PM UTC, comment #8: 


Sadly, I guess this is the safest and best choice. The obvious
negative is that JIT will get less exposure.  It will
be good to make sure that packagers are aware of this
change so that, if they are packaging for hardware and
systems that work they need to use --enable-jit.

Michael Godfrey <godfrey>
Project Member
Mon 13 Jan 2014 04:37:38 PM UTC, comment #7: 

We had this discussion before the 3.8.0 release, but I think it is worth re-opening.  The default for the JIT compiler is to compile it if LLVM is available, but not to turn it on at runtime.  This seemed safe enough, but apparently it isn't.

For the compilation phase, there is bug #41163 when compiling with 64-bit indexing and JIT, and there was bug #41114 when compiling with a Homebrew version of LLVM on a mac.

At run time, even when JIT is not enabled it will be turned on by jit.tst when running the test suite.  This produces segfaults on non-x86 processors (this bug report), and also on x86 processors which aren't running Linux (bug #40608).

It seems that the only combination really tested, Linux on x86, is the only one that is stable--Everything else is a crap shoot.

Given that JIT is going to get no attention on the 3.8.X or 4.0 releases it seems best to simply default it to being off entirely unless someone uses the '--enable-jit' option.

Rik <rik5>
Project Administrator
Mon 13 Jan 2014 01:32:13 AM UTC, comment #6: 

Currently, when no option (--enable-jit or --disable-jit) is given then configure.ac checks for the presence of LLVM and goes ahead and builds the JIT compiler if it is present.  Thus, configure will respect any explicitly given option.  What needs to be coded is a test on $host_os to disable JIT compilation when no option has been specified and the architecture is not x86, x86_64.

Rik <rik5>
Project Administrator
Mon 13 Jan 2014 01:08:06 AM UTC, comment #5: 

Disabling it for non-x86 for now sounds fine to me.

Would there be a way to override this so a developer could easily enable it for working on JIT on ARM for example?

Mike Miller <mtmiller>
Project Administrator
Sun 12 Jan 2014 11:31:50 PM UTC, comment #4: 

Rik said:
"Should we turn it off for anything beside x86?"

I think that this is the best short-term choice.
A warning that says "JIT is operational only for x86"
would be useful if it is turned off at configure time
for this reason.

leaving it as it is has the defect that a non-x86 user could
turn it on at execution time and then suffer seg faults.

x86 means x86 and x86_64.

Michael Godfrey <godfrey>
Project Member
Sun 12 Jan 2014 10:36:13 PM UTC, comment #3: 

The way Octave's tests currently work there is no way to continue after a segfault.  That's just fatal.  So we need to have a way to disable the tests by default or just disable JIT compilation completely in released versions until it can reasonbly be expected to work.

John W. Eaton <jwe>
Project Administrator
Sun 12 Jan 2014 10:28:15 PM UTC, comment #2: 

Yeah I realize this is probably because all development has been on x86 and this is a brand-new feature. Just filing as something to keep track of for future development, maybe better done as a task or project idea on the wiki?

For the short term, I don't think it hurts much to leave things as they are. There is no compilation failure, JIT is labeled experimental and is disabled by default at runtime. Configure could issue a warning if anything. Packagers can work around this in distro-specific build scripts as needed if they choose to enable JIT support.

Mike Miller <mtmiller>
Project Administrator
Sun 12 Jan 2014 10:07:30 PM UTC, comment #1: 

What is a sensible short-term solution? JIT is still experimental, should we turn off compilation for all platforms?  Should we turn it off for anything beside x86?

Rik <rik5>
Project Administrator
Sun 12 Jan 2014 09:52:33 PM UTC, original submission:  

Running the JIT unit tests in "make check" segfaults Octave on non-x86-based machines.

See for example the build log at


Mike Miller <mtmiller>
Project Administrator


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by dac922 (Posted a comment)
  • -email is unavailable- added by godfrey (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 mtmiller (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 project members can vote.





    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-21 pantxo StatusPostponed Wont Fix
        Open/ClosedOpen Closed
    2016-11-17 rik5 Priority3 - Low 1 - Later
    2016-11-17 mtmiller Release3.8.0 dev
    2015-04-25 rik5 Priority5 - Normal 3 - Low
    2014-01-23 rik5 StatusNone Postponed

    Back to the top

    Powered by Savane 3.9