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
   

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>
Group Member
Tue 21 Dec 2021 03:17:46 AM UTC, comment #13: 

Close this bug because no more JIT?

Anonymous
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>
Group 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>
Group 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>
Group Member
Mon 13 Jan 2014 06:32:36 PM UTC, comment #8: 

Rik,

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>
Group 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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group 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>
Group Member
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>
Group 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

https://buildd.debian.org/status/fetch.php?pkg=octave&arch=armel&ver=3.8.0~rc2-1&stamp=1388884967

Mike Miller <mtmiller>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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 group 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.13-cf05.
    Corresponding source code