Octave-4.4.0 rc1 and beta9 crash on older Macs: Illegal Instruction about octave-app HOT 43 CLOSED

I'm seeing the same thing. Older iMac, High Sierra 10.13.6, downloaded Octave-4.4.0-rc1.dmg, dragged it to Applications, opened it, verifying, and nothing.

from octave-app.

Addendum... So I installed it with brew, which placed Octave-4.4.0.app in /Applications, and that works.

from octave-app.

from octave-app.

octave-gui crashes after install on MacOS 10.13.6

from octave-app.

@lewisde can you give me some more information, e.g. when does it crash? Do you see that the icon pops up etc.? I just verified (again) that the 4.4.0 rc1 is running on my machine with both macOS 10.13.6 and the recent 10.14 release candidate.

from octave-app.

I'm also having this issue. The icon shows in the dock very briefly, but it crashes essentially instantly.

from octave-app.

@paul-snively we do not see this issue on our machines. We expect a problem of cpu architectures (i.e., that we compile for a more modern cpu instruction set and yours cannot execute its byte code). What mac do you use? Could you try octave on another (newer) mac? Did any beta work for you?

from octave-app.

@schoeps for reference I am running macOS High Sierra on a MacBook Pro (Retina, 15-inch, Late 2013) which is a 2.3 Ghz Intel Core i7 processor, 16 GB ram, and the NVIDIA GeForce GT 750M card (in case Octave also takes advantage of GPUs).

In the meantime I'm using homebrew to learn Octave, but I'm hoping to have an easy way to download a version with the UI before classes start again in a few weeks.

from octave-app.

@dontillman Hold on:

So I installed it with brew, which placed Octave-4.4.0.app in /Applications, and that works.

Really? brew install octave should install into /usr/local/ (or your custom prefix), and does not create an "Octave.app" app bundle at all. As far as I'm aware, our Octave.app installer is the only thing that would create an /Applications/Octave-4.4.0.app. I'm wondering if there is an unintended interaction between our Octave.app and Homebrew-installed Octave dependencies, possibly related to user-specific environment variables.

Do you remember the exact command you used to install with brew?

from octave-app.

I may have missed something, but the Octave-4.4.0-beta4 worked fine on both systems.

The main differences between beta7/rc1 and the older beta4 are:

• It's built on OS X 10.11 El Capitan for back-compatibility, instead of being built on 10.13 High Sierra.
• It fixes the CPU architecture for the build of the gmp library (https://github.com/octave-app/octave-app-bundler/issues/42)

So if it appeared since then, it's probably related to one of those.

Do any of you have files in ~/Library/Logs/DiagnosticReports? Some crashes may produce logs there.

from octave-app.

@kriswuollett

In the meantime I'm using homebrew to learn Octave, but I'm hoping to have an easy way to download a version with the UI before classes start again in a few weeks.

If you can't get Octave.app working for now, you can also try using our (experimental) GUI-enabled Homebrew Octave formula found at https://github.com/octave-app/homebrew-octave-app-bases/blob/master/Formula/octave-octave-app.rb. It's not as easy to install, but it may get you up and running.

To install it, do:

brew unlink octave
brew tap octave-app/octave-app-bases
brew install octave-octave-app

...and then sit back and wait, because the build takes an hour or more. Then, once it's installed, run octave --force-gui.

from octave-app.

Sorry for the slow response on this; I've been busy with the day job and travel.

I'll try building a completely-clean 10.13.6 VM to see if I can reproduce this behavior.

from octave-app.

As per apjanke's instructions (thanks!) I downloaded the current Octave-4.4.0-rc1.dmg and installed it; the binary crashes with message "Illegal instruction: 4."

sw_vers shows:
ProductName: Mac OS X
ProductVersion: 10.12.6
BuildVersion: 16G1510

I had various versions of octave installed so made sure all were removed; otool -L suggested only libraries from /usr/lib and /System/Library/Frameworks/ were linked (other than those included with the app.) The stacktrace from the thread that crashed is included below (from the OSX crash log.)

I'll try the instructions earlier in this thread for building using brew now.

Thread 8 Crashed:: QThread
0   liboctave.5.dylib                   0x0000000110b73458 void octave_sort<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::binarysort<bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, long long, long long, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)) + 38
1   liboctave.5.dylib                   0x0000000110b67801 void octave_sort<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::sort<bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, long long, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)) + 369
2   liboctave.5.dylib                   0x0000000110fbdf3e string_vector::sort(bool) + 50
3   liboctinterp.5.dylib                0x000000011026a921 octave::genpath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, string_vector const&) + 130
4   liboctinterp.5.dylib                0x000000011026178e maybe_add_path_elts(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 51
5   liboctinterp.5.dylib                0x00000001102613cd octave::load_path::initialize(bool) + 255
6   liboctinterp.5.dylib                0x000000011025a31c octave::interpreter::initialize_load_path(bool) + 344
7   liboctinterp.5.dylib                0x000000011025a527 octave::interpreter::initialize() + 49
8   liboctgui.3.dylib                   0x000000010f897d33 octave::octave_interpreter::execute() + 57
9   org.qt-project.QtCore               0x000000011265c201 QObject::event(QEvent*) + 801
10  org.qt-project.QtWidgets            0x0000000112f75d2d QApplicationPrivate::notify_helper(QObject*, QEvent*) + 301
11  org.qt-project.QtWidgets            0x0000000112f77131 QApplication::notify(QObject*, QEvent*) + 529
12  org.qt-project.QtCore               0x0000000112631d04 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 164
13  org.qt-project.QtCore               0x0000000112632ebb QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 891
14  org.qt-project.QtCore               0x000000011268a119 QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 73
15  org.qt-project.QtCore               0x000000011262d671 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 417
16  org.qt-project.QtCore               0x000000011246d383 QThread::exec() + 115
17  org.qt-project.QtCore               0x0000000112476c67 0x112448000 + 191591
18  libsystem_pthread.dylib             0x00007fffab82c93b _pthread_body + 180
19  libsystem_pthread.dylib             0x00007fffab82c887 _pthread_start + 286
20  libsystem_pthread.dylib             0x00007fffab82c08d thread_start + 13

from octave-app.

@rpgit12 Do you know what model Mac you're running on? (So we can determine what CPU generation you're running?)

from octave-app.

@apjanke the instructions you gave above for building the Homebrew version was able to build the app, and it launches for me. I do not have any specific tests more than that at this point. However during the process I had to brew unlink sundials during the process, and then brew unlink octave followed by brew link octave-octave-app. Based on my command history the last two were probably a mistake on my part since it looks like I only tried rew unlink octave before your instructions.

from octave-app.

@apjanke you had found a command line tool that figures out the instruction sets used in an executable, right? If you recall the name then @kriswuollett could let us know how his build differs from ours...

from octave-app.

@apjanke

Do you know what model Mac you're running on?

MACBOOK PRO (RETINA, 15-INCH, LATE 2013)
running MacOS Sierra 10.12.6

from octave-app.

Thanks @apjanke - your experimental brew formula worked and octave --gui works. (Now on to Andrew Ng's homework #1 ... )

from octave-app.

@dontillman

Really? brew install octave should install into /usr/local/ (or your custom prefix), and does not create an "Octave.app" app bundle at all.

Oh, wait - I had completely forgotten that we supply an octave-app/octave-app Cask. It was left on Beta 4, so doing a brew cask install octave-app/octave-app would have installed the older version. Which would mean the crash was introduced between beta4 and beta7, which is consistent with what @mpiqueca is seeing.

from octave-app.

you had found a command line tool that figures out the instruction sets used in an executable, right?

Yep, it's elfx86exts.

from octave-app.

Aha:

[/Applications/Octave-4.4.0.app/Contents/Resources/usr/lib]
$ $elfx86exts libfontconfig.dylib
MODE64 (push)
CMOV (cmovne)
AVX (vmovaps)
BMI (bextr)
ADX (adcx)
BMI2 (mulx)

There's that pesky Haswell BMI2 instruction again, cropping up in fontconfig's library. And that ADX instruction set is from Broadwell. That's consistent with the program crashing when run on older Macs at the point where it calls a fontconfig function, including the Late 2013 MacBooks. I'm seeing it in a bunch of other library files, too. This build is bad.

Maybe I was mistaken in removing the HOMEBREW_OPTFLAGS here. I thought that was internal-use only, but maybe it isn't. And it does seem like it's in the right topic area.

from octave-app.

Ah: This munging of build_bottle? is apparently not working. Checked in an attempted fix here and doing a new build now.

from octave-app.

Here is the output of elfx86exts on octave on my machine:

Kristophers-MacBook-Pro:elfx86exts kris$ target/debug/elfx86exts /usr/local/bin/octave
MODE64 (push)
AVX (vmovaps)
CMOV (cmovne)
BMI2 (shlx)
BMI (bextr)
Kristophers-MacBook-Pro:elfx86exts kris$ find /usr/local/ -name 'libfontconfig.dylib' -exec echo '{}' \; -exec target/debug/elfx86exts '{}' \;
/usr/local//lib/libfontconfig.dylib
MODE64 (push)
CMOV (cmovne)
SSE1 (movaps)
SSE2 (movq)
/usr/local//Cellar/wine/3.0_2/libexec/lib/libfontconfig.dylib
thread 'main' panicked at 'can't parse object file: "Unknown file magic"', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
/usr/local//Cellar/fontconfig/2.13.0/lib/libfontconfig.dylib
MODE64 (push)
CMOV (cmovne)
SSE1 (movaps)
SSE2 (movq)
/usr/local//Cellar/fontconfig/2.13.1/lib/libfontconfig.dylib
MODE64 (push)
CMOV (cmovne)
SSE1 (movaps)
SSE2 (movq)

from octave-app.

Thanks @kriswuollett. That's consistent with what I'm seeing, and since it's affecting multiple binaries, I think a broken build_bottle munging is the culprit. Rebuild is still running (it stalled due to a failed little_cms download) and I should have a fixed RC2 build posted tomorrow evening.

from octave-app.

I've posted a new beta8 build which I think fixes all these crashes: https://github.com/octave-app/octave-app/releases/tag/v4.4.0-beta8

I'm calling it beta8 instead of RC2 because:

• the build size has increased a lot (+200 MB for the compressed DMG), and I have no idea why
• there's a new bug that should be sorted out before 4.4.0: https://github.com/octave-app/octave-app-bundler/issues/50

Please install and test at your convenience, and let me know if it's still broken for you.

from octave-app.

I have just tried RC1 and then beta9 and I'm still getting what I think are the same crashes as described above. So it doesn't look like it's fixed yet.

"Illegal instruction 4" when launched from the Terminal, and the "octave-gui quit unexpectedly" when opening from Finder.

I have an older version that is working fine, installed on May 3 from a "Octave_44_Yosemite.dmg" downloaded from a link posted by Sebastian on octave-maintainers.

This is on a macOS High Sierra 10.13.6 on a MacBook Pro (Retina, 15-inch, Mid 2014), 2.8 GHz Intel Core i7.

I'm happy to provide more info, including crash logs from my current install (beta9) if you like.

from octave-app.

Darn it. This time, I cannot reproduce the crash on my older MacBook.

Yeah, could you post the crash log from a beta9 run?

from octave-app.

Here you go.

beta9-crash-log.txt

from octave-app.

v4.4.0-beta8 starts up fine for me on MacBook Pro (Retina, 15-inch, Late 2013) with macOS 10.14. I don't have any current Octave projects going. Let me know if there's something I can run to test.

from octave-app.

Thanks @rdzman.

I think this is the relevant excerpt from the crash log:

Crashed Thread:        11  QThread

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [0]

[...]

Thread 11 Crashed:: QThread
0   liboctave.5.dylib             	0x000000010e7f9458 void octave_sort<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::binarysort<bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, long long, long long, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)) + 38
1   liboctave.5.dylib             	0x000000010e7ed801 void octave_sort<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::sort<bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, long long, bool (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)) + 369
2   liboctave.5.dylib             	0x000000010ec43f3e string_vector::sort(bool) + 50
3   liboctinterp.5.dylib          	0x000000010def6921 octave::genpath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, string_vector const&) + 130

It's our good old Illegal Instruction error all right, and it's in liboctave.5.dylib, which means it's part of the core Octave build.

from octave-app.

OMG, kill me. It's a regression in beta9; beta8 works fine, but beta9 reproduces the crash for me on my Mid 2012 Retina MBP.

I will investigate what caused the beta9 build to go bad; I didn't think I changed anything related to architectures.

from octave-app.

What if we buy an old mac that does not support the fancy modern instructions? (I guess your mac mini is already to new)

from octave-app.

What if we buy an old mac that does not support the fancy modern instructions?

I already did! I just didn't test beta9 on it since it was such a trivial change from beta8 that I didn't think it would matter. More fool me.

from octave-app.

What if we buy an old mac that does not support the fancy modern instructions?

I already did! I just didn't test beta9 on it since it was such a trivial change from beta8 that I didn't think it would matter. More fool me.

I am confused. Why aren't we compiling on that machine?

from octave-app.

And we could check this CPU-independently in software with that elfx86exts program, too. If I have time, I'll add a portability-validation step in to the build process: have it scan all the built exes and dylibs and check for too-new instruction sets.

from octave-app.

Why are we not compiling on that machine?

A) Because it's super old and slow, and it's not running El Cap as its main host operating system. The El Cap VM on my 5K iMac can build Octave.app an hour faster than my old Core2 test MacBook can.

B) Because I think we should aim for having a build system that can build a portable Octave.app on any Mac hardware, so it doesn't require us or future maintainers to buy special obsolete machines, and so all our users can do the build if they want to, too. Homebrew's got the support for this; there's just something we're not quite getting right here.

from octave-app.

Also, C) I would like to keep that old test machine super-clean, with none of the build mechanisms on it, so it's a clean test environment that is more like end-user machines that only download the final Octave.app DMG and don't have any of our build infrastructure set up. I think that makes for a better test of the final user experience. In general, and given how we've seen interaction between Octave.app and an external Homebrew install before (with that Fortran compiler issue), I think it's good to have a pristine testing environment.

from octave-app.

I am already convinced :)

Talking about being portable: you started versioning homebrew dependencies but this makes the installation of octave within an existing homebrew environment cumbersome.

Would it make sense to add a subrepo of homebrew-core to our octave-app and keep its version (even if outdated). We could modify the homebrew update mechanism to point to our repo such that it does not detect updates. This would allow us to maintain only one more repository for octave.rb? (and sundials at the moment).

By the way: https://github.com/andreyvit/create-dmg is active again!

from octave-app.

[...] this makes the installation of octave within an existing homebrew environment cumbersome.

Can you be more specific about what you mean by "cumbersome"? I've tried to set this up so it works as well as it can within Homebrew, as well as through a DMG install.

In terms of commands, I think it's pretty easy to use. If you want the latest:

$ brew tap octave-app/octave-app-bases
$ brew install octave-octave-app

If you want a specific version:

$ brew tap octave-app/octave-app
$ brew install octave-octave-app_4.4.0

That 4.4.0 will remain available once 4.4.1 and later versions exist.

Users do have to then sit there and wait maybe hours while it builds. Cumbersome, and unfortunate. But hard to get around, due to https://github.com/octave-app/octave-app-bundler/issues/2.

Would it make sense to add a subrepo of homebrew-core to our octave-app and keep its version (even if outdated).

Depends on what your goals are. I think our existing homebrew-octave-app and homebrew-octave-app-bases repos might already suffice here. As long as you just want the "latest and greatest" build of Octave.app's Octave for each Octave release version, instead of a full release history.

The homebrew-octave-app tap contains a versioned octave-octave-app_4.4.0.rb file for installing our customization of Octave 4.4.0 within Homebrew. And I expect that to remain when we add a 4.4.1 version. The gotcha is that if there are revision (as opposed to version) bumps in dependencies, then only the newer versions of dependencies' dependencies will be visible. See https://github.com/octave-app/octave-app-bundler/issues/47. That's why I'm suggesting (in other bugs) using branches to track the full history of the Octave.app formulae, so you can "go back in time" and reproduce the exact build that produced a given Octave-X.Y.Z.dmg.

These taps keep all the outdated versions of octave and all its dependencies; just not revisions within those versions.

Does that make sense?

By the way: https://github.com/andreyvit/create-dmg is active again!

Oh, nice! I'll see about pushing our customizations upstream.

from octave-app.

I found the reason that beta8 and beta9 blew up in size. This was due to an upstream issue with Homebrew that caused the git installation to get 300 MB larger.

Upstream issue: Homebrew/brew#4921

This has since been worked around in brew and builds are back to the old size.

[~/tmp/octave-size-comparison/beta9/Octave-4.4.0.app/Contents/Resources/usr/Cellar]
$ du -sh git
327M	git
[~/tmp/octave-size-comparison/beta10/Octave-4.4.0.app/Contents/Resources/usr/Cellar]
$ du -sh git
 43M	git

from octave-app.

Okay, I think I have this fixed.

I have posted a new beta10 build: https://github.com/octave-app/octave-app/releases/tag/v4.4.0-beta10. Please download and test at your convenience.

This build, I have tested on my old Ivy Bridge mid-2012 MacBook Pro, and checked using elfx86exts. Runs without crashing, and no BMI/BMI2 instructions present.

[/Applications/Octave-4.4.0.app/Contents/Resources/usr]
$ $elfx86exts bin/octave
MODE64 (push)
SSE1 (xorps)
CMOV (cmovne)
[/Applications/Octave-4.4.0.app/Contents/Resources/usr]
$ $elfx86exts lib/octave/4.4.0/liboctave.5.dylib
MODE64 (push)
CMOV (cmovno)
SSE1 (xorps)
SSE2 (movq)
[/Applications/Octave-4.4.0.app/Contents/Resources/usr]
$ $elfx86exts lib/libfontconfig.dylib
MODE64 (push)
CMOV (cmovne)
SSE1 (movaps)
SSE2 (movq)

The cause for that bad beta9 build: somehow my local octave-app-bundler repo on the build box had gotten out of sync with the master on GitHub, and it had a regression for the build_bottle test munging.

And this build is back down to the old size, thanks to the upstream Homebrew fix.

from octave-app.

I can confirm that beta10 runs fine on my MacBook Pro (Retina, 15-inch, Mid 2014), 2.8 GHz Intel Core i7 running macOS High Sierra 10.13.6.

Thanks.

from octave-app.

That's one confirmation this is fixed, and no adverse reports. I'm closing this out as fixed.

from octave-app.