Why am I unable to start or install MATLAB on my Mac Pro (2013 or newer) with two Thunderbolt displays?

If I connect two Thunderbolt displays to my new Mac Pro I am not able to run or install MATLAB. Is there any workaround?

These are the errors from Console and Crash logs:

A fatal error has been detected by the Java Runtime Environment:

#

# SIGSEGV (0xb) at pc=0x000000010ef43400, pid=13024, tid=5891

#

# JRE version: 7.0_11-b21

# Java VM: Java HotSpot™ 64-Bit Server VM (23.6-b04 mixed mode bsd-amd64 compressed oops)

# Problematic frame:

# C [libinstutil.dylib+0x9f400] l_getid_type+0xded

Or:

Java quit unexpectedly

Click Reopen to open the application again. This report will be sent to Apple automatically.

Answer 1

[MathWorks Support Team]

Background information

MathWorks is aware of a bug in MATLAB R2014a, R2014b, and R2015a related to MATLAB's licensing components which can affect the Mac Pro (2013+). This issue has been reported to the vendor (Flexera Software) responsible for MATLAB's licensing components. Many hardware configurations are affected, but a Mac Pro (2013) with two Thunderbolt Displays connected is particularly susceptible to this bug.

The bug will manifest itself on any hardware configuration where "ifconfig" reports more than ten "en" (Ethernet) interfaces. Since Thunderbolt Displays contain multiple network interfaces, connecting more than two of them to a Mac Pro (2013) will cause the Ethernet interface count to rise above ten. The Mac Pro (2013+) has nine built-in Ethernet interfaces, and Thunderbolt Displays contain an additional Ethernet interface which therefore increases the total Ethernet network interface count by one when a Thunderbolt display is connected.

To confirm whether a Mac is susceptible to this bug, launch the Terminal application and enter "ifconfig" at the prompt. A series of network interfaces will be listed. If the number of entries starting with "en" is greater than ten, then the Mac is susceptible.

This bug was resolved in MATLAB R2015b.

Workaround 1: Update to R2015b or later (Recommended)

This bug was fixed in MATLAB R2015b. The simplest way to resolve this issue is to update to R2015b or later.

*Workaround 2: Disconnect Extra Displays *

Disconnect devices from your Mac which add additional Ethernet network interfaces to reduce the total Ethernet interface count to ten or less. If you have multiple Thunderbolt Displays, disconnecting all but one of them is the quickest way to bring the count back down to ten.

When applying this workaround, devices disconnected cannot be reconnected while MATLAB is running. Doing so can cause the error to occur.

Workaround 3: Disable Thunderbolt Networking (Advanced Users)

NOTE: If you are not familiar with Terminal, please consult your IT department or use the recommended workaround listed above.

As an alternative workaround, you may run a command listed below, which will reduce the number of Ethernet interfaces until the next reboot by disabling IP-over-Thunderbolt functionality which most users do not need.

This will not unload your Ethernet or Wi-Fi interfaces, even those on your Thunderbolt Displays. This does not impact any other functionality of Thunderbolt. If you need to use these interfaces after unloading them, this is possible with another terminal command, or you can simply restart your Mac.

These devices must remain unloaded during your MATLAB session. If you decide to reload them, your MATLAB session may crash.

To unload the IP-over-Thunderbolt network interface, run the following command in Terminal (this command must be run each time your Mac restarts):

 sudo kextunload -v /System/Library/Extensions/AppleThunderboltIP.kext

If you need to reload them (without restarting your Mac) you can run the following command in Terminal:

 sudo kextload -v /System/Library/Extensions/AppleThunderboltIP.kext

[Andrew Roberts]

Mathworks: Please provide an update on the progress being made on this issue. We are now into July and this issue needs to be resolved as soon as possible. I am currently using R2013b because I cannot use r2014a, however even this needs to be reinstalled every time I reboot the Mac Pro, as it fails with a licensing error.

[Case Five]

Caveat Emptor, etc.

I've solved this issue for my mac by some command-line trickery, disabling the .kext file that allows a Thunderbolt port to count as a network interface.

Potential side effects:

• Can't use the ethernet ports in my monitors (which I don't care about, because, who would).
• Can't use the FW ports in my monitors as a network interface (which I don't care about, because, also, who would).
• Can't use a Thunderbolt -> Ethernet adapter on my monitors or MacPro tower (which I don't care about, because, again, honestly, who would?).

Please be oh so careful when trying this if you're not familiar with the command line:

sudo kextunload /System/Library/Extensions/AppleThunderboltIP.kext

Reversible via:

sudo kextload /System/Library/Extensions/AppleThunderboltIP.kext

Also will reverse itself on reboot, which will make your IT department happy.

I've just aliased the kextunload step and run it if I've rebooted since the last time I used Matlab, which doesn't come up for me a lot.

Things that did not work for me:

• ifconfig $blah down (repeating for all the FW and Display Ethernet interfaces by hand)
• Using the GUI to disable or delete the unused interfaces, as they still are counted by the system. If you found a way to reproduce the interface count reduction using the GUI please do respond and let me/us know.

Good luck!

-Case

[Larrabee Strow]

Thank you thank you!! I also don't care about the monitor ports! Works great!

[Joseph MacGregor]

Thanks, Case Five!!!! This definitely works. Mathworks Support should owe you a beer or six, at least!

[Scott]

Case,

Thank you very much for bringing this workaround to our attention. We've tested it, and it seems to be almost 100% effective. As such, we've amended the solution to include this workaround.

Thanks again,

- Scott

[Craig]

OK, but what about those of us that use these ports? The Mac Pro I'm on here isn't using a Thunderbolt Display but is using a Kanex Thunderbolt to 10G ethernet adapter. VMWare is going as well and as a result, I end up with en0-en11. I can't disable the Thunderbolt IP kext as that's where my main 10G connection comes in.

[Scott]

Hi Craig,

If you're using a Thunderbolt-to-Ethernet adapter then you're not using IP-over-Thunderbolt. Your Mac sees the Ethernet adapter as just another Ethernet interface. IP-over-Thunderbolt only applies when you are not using an Ethernet adapter, and you're connecting to the network directly with a Thunderbolt cable.

As there are not currently any routers or switches which have Thunderbolt ports, we don't think that anyone is using this functionality. Typically, IP-over-Thunderbolt internet is only used to directly connect two Macs via a Thunderbolt cable. It should be safe to unload that kext file in your use case.

-Scott

[Jonathan]

I made an little Automator application that does this on command, in case anybody is interested. You can get it at

http://birge.us/public/?dir=matlab

In case you're worried, you should be able to open the application in Automator and confirm that it's not doing anything malevolent.

[Alex]

Has this bug been fixed in R2015b?

[Abhishek Pandey]

Hi Alex. This bug has been fixed in R2015b.

Answer 2

[Min H. Kim]

I'm the one who addressed this issue to Mathworks about seven months ago. I'm currently using Matlab on a virtual machine instead of using the native workstation, Mac Pro w/ two thunderbolt displays. I expected a bug fix in this new version of Matlab 2014b and was disappointed in customer service, finding that the critical bug (addressed in seven month ago) remains in this latest update. Mathworks must publically and clearly announce that "Their latest product of Matlab cannot be run properly on a high-end configuration of Macintosh computers" in advertisements and product specifications. It is a serious liability issue to customers, who purchased this Matlab product of Mac without knowing this fact! Mathworks must realize that the importance of this bug fix and their liability to customers. Either Mathworks or the licensing product vendor (Flexera) must fix this faulty product at least by providing a bug patch as soon as possible.

[Jun Kyung Auh]

I am having the same problem. I emailed few times with a Mathwork staff and his tone was like "it is the problem of Flexera, not ours." And also, they made a silly excuse that "our product works well on other machines, even the most extreme machines in the world." I don't care whether their product works on aliens' computers. This is truly disappointing response. Now that 2014b came out but they said their vendor did not fix the problem so nothing is solved.

[Larrabee Strow]

I am yet another user who cannot use MatlabR2014x with my Mac Pro. I do Matlab all day long and bought this machine in order to get more done... I can use R2013b, but my target high-performance clusters will soon stop supporting R2013b, which may cause me grief.

This is indeed very disappointing for a 20+ year customer.

Mathworks should pay more attention to their high-end users.

Larrabee

[Andrew Roberts]

I experienced a similar "it's not our problem" response from Mathworks as detailed above. I have $10,000 worth of new computing equipment sitting on my desk that cannot run the latest version of MATLAB without disconnecting all but one screen, or running the command: sudo kextunload /System/Library/Extensions/AppleThunderboltIP.kext As detailed above. However, I agree about the customer service. I work on some of the fastest supercomputers in the world, and find the response of Mathworks strange. I purchased a Mac Pro with multiple screens because the hardware happens to be one of the best desktops around for scientific post-processing.

[Gideon simpson]

Mathworks really needs to step up on this kind of thing. Python just keeps getting better and better, and these kinds of issues are typically resolved quickly by the open source community. If Mathworks expects us to keep forking over significant amounts of money, that had better provide us with something that the open source community can't.

[Shawn Lyons]

@Gideon Simpson

A fix for this issue is in the works for an upcoming release, likely version R2015b.

-Shawn

MathWorks Support

Answer 3

[Min H. Kim]

Well... Here is an adhoc solution to make your launching simpler on your Mac. I wrote a simple bash script to launch Matlab 2015a in your command-line window on a Macro with two thunderbolt displays. Just type this in your command-line window as follows:

macpro$ runmatlab.sh

I'm using this on my computer, and it seems to work smoothly.

One thing tedious... You have to type your sudo password in your command-line window before launching Matlab. Just download, uncompress and copy this script where your path is set on your computer. I hope this script helps other people in our science and engineering community. - Min

Answer 4

[Joseph MacGregor]

I am disappointed to report that this issue persists in R2015a. The solution still works, thankfully, but it doesn't speak well to the ability of Mathworks and Flexera to work together to fix identified problems in a timely manner. Step it up, guys.

[Shawn Lyons]

@Joseph MacGregor

A fix for this issue is in the works for an upcoming release, likely version R2015b.

-Shawn

MathWorks Support

[Jonathan]

What's the point of bi-yearly updates if a bug of this significance and magnitude can't be addressed by the next update? You guys are putting out two updates a year but only doing work worthy of one every two years, at best...