"library initialization failed - unable to allocate file descriptor table - out of memory MATLAB is exiting because of fatal error"

Hi!

I'm a Linux user and today I started receiving the following error message when launching MATLAB:

MATLAB is selecting SOFTWARE OPENGL rendering. 
library initialization failed - unable to allocate file descriptor table - out of memory 
MATLAB is exiting because of fatal error 
[1]    10520 killed     matlab

It was working correctly until now, not sure it could have something to do with a software update. However, if I execute matlab with the -nojvm flag it opens the console properly.

I'm using MATLAB R2023a in Debian trixie kernel version 6.7.12.

Thanks for your help!

Answer 1

[Alberto Fernández Pena]

Hello,

I've managed to solve this with the help from the Mathworks Technical Support Team. It seems to be a problem with Java.

I first tried to set ulimit -n and ulimit -u to the ones defined here https://mathworks.com/help/parallel-computing/recommended-system-limits-for-macintosh-and-linux.html but it didn't work.

EDIT:

I found that my error was related to the Java version shipped with MATLAB. Two options worked for me.

Option 1:

Install Amazon Corretto Java https://www.mathworks.com/support/requirements/openjdk.html and set this as the default JRE (https://es.mathworks.com/matlabcentral/answers/103056-how-do-i-change-the-java-virtual-machine-jvm-that-matlab-is-using-on-macos)

This option doesn't require root access, but in my case, MATLAB took over a minute to start.

Option 2:

Increasing the hard open files limit. I'm not sure why this worked but ulimit -n didn't.

For me this solved the problem, no need to change to Corretto Java:

echo > /etc/security/limits.d/systemd.conf "* hard nofile 65536"

I needed to reboot after setting this file so the changes were loaded.

I want to thank the Mathworks Technical Support Team for their help and patience.

[Sabrina]

I am having the same problem with running Matlab on Debian Trixie.

That solution seems quite invasive, though. I have to change root-level security configurations in my system. That does not feel right. Did anyone else try that solution? If yes, did it work without any issues?

[alberto maurizi]

Agree with you: it is not the bes to mess with system limits.

Anyway, that solution does not even work for me. Maybe my problem is that I do not really understand if the problem is related to some upgrade of java environmente in debian/sid (the distrib I'm using).

For sure matlab works fine in debian/stable (R2023a).

What is more frustrating is that error messages do not give hints on how to diagnose the problem.

[alberto maurizi]

@Alberto Fernández Pena, can you transform your solution into a step-by-step HOWTO?

[Alberto Fernández Pena]

Hi, I've updated my previous response. I hope it's clear now. You might need to reboot your system after the changes.

Good luck.

[alberto maurizi]

That's much more clear, thank you.

However, following your suggestion (changing the limit on the number of open files), I found it easier (and maybe cleaner) to use ulimit:

ulimit -n 2048 worked for me as a user, no need to reboot.

[Calum]

The important thing is that the hard limit is reduced to prevent matlab from attempting to make a table for every file descriptor it would be permitted to allocate (which is a lot). ulimit changes don't hold over reboots; you need to call it every time matlab is run, for instance by modifiying the shell script that launches it.

There is a matlab bug in whatever software expands that limit so high

[Dmitry Boltyanskiy]

Does not work for me.

[Lorenzo Pagnini]

Thanks very much, option 2 worked for me (Debian GNU/Linux trixie/sid)

[Timothy]

Option 2 also worked for me (Ubuntu 24.10 running Matlab 2024b), thanks!

[Chris J]

and me, thanks

Answer 2

[Adailton Júnior]

The same here.

Until last week it worked fine. I tried to open it today and got the same error.

OS: Debian GNU/Linux trixie/sid x86_64

Host: G3 3500

Kernel: 6.7.12-amd64

Uptime: 11 hours, 48 mins

Packages: 4131 (dpkg), 17 (flatpak), 15 (snap)

Shell: bash 5.2.21

Resolution: 1920x1080

DE: Plasma 5.27.11

WM: kwin

Theme: [Plasma], Breeze [GTK2/3]

Icons: [Plasma], breeze [GTK2/3]

Terminal: terminator

CPU: Intel i5-10300H (8) @ 4.500GHz

GPU: NVIDIA GeForce GTX 1650 Ti Mobile

GPU: Intel CometLake-H GT2 [UHD Graphics]

Memory: 4237MiB / 7742MiB

[alberto maurizi]

It also happened here. It must be related to some debian/sid upgrade. But which one?

What seems clear enough is that it is related to java. But from the @Alberto Fernández Pena solution it is not clear enough (to me, at least) what to do .

[Adailton Júnior]

I was able to solve the problem with @Alberto Fernández Pena's Option 2. Don't forget to reboot.

Answer 3

[Shivani]

Hello @Alberto Fernández Pena,

You may be encountering this issue due to a recognized bug in the software. This bug has been resolved starting with MATLAB R2016b. However, as part of your troubleshooting efforts, it might be beneficial to explore the workarounds provided in the External Bug Report. You can access the External Bug Report via the following link: https://www.mathworks.com/support/bugreports/1297894?s_tid=mwa_osa_a

Additionally, you can refer to the following MATLAB Answer thread that addresses a similar issue: https://www.mathworks.com/matlabcentral/answers/337113-error-matlab-is-selecting-software-opengl-rendering

If the workarounds provided in the above links do not resolve the issue, then please contact the MathWorks Technical Support Team through the following link, as they will be able to provide an accurate resolution for this error.

https://www.mathworks.com/support/contact_us.html

[Alberto Fernández Pena]

Hi, @Shivani:

Thanks for your answer. The workarounds you mentioned don't seem to solve the issue. I've tried with R2024a and I have the same problem.

I'm getting in touch with the Technical Support Team to see if they have a solution.

Thanks.

Answer 4

[Calum]

Coming back because I couldn't figure out an elegant fix. The problem isn't (contrary to what you might think with ulimit) a lack of file descriptors. Rather, it is an excess. Matlab apparently 1) raises the soft limit of file descriptors to whatever the hard limit is (a lot), and then 2) attempts to allocate a table of every single one of those descriptors that is available.

On my system, the hard limit for file descriptors is 1,073,741,816. Obviously, that is too many for matlab to use. They should probably look at fixing this bug.

The ulimit -n solution works because ulimit changes both the hard and soft limits by default. You just need to make sure it is run every time Matlab is, for instance by putting it in the matlab shell file.