Does anyone have any updates per @Fitti 's issue? I am still having the same identical stack trace that he is having. For reference, I will post it here as well. I have tried the execstack/patchelf commands on the usual suspects per the comments here and on other arch forum posts. I can ask there if they may be of more help.
It is also to note that this stared after authorization, as the stack trace would obviously suggest. Before this, the fixes to the gnutls package that was posted earlier worked like a charm and the app will fully launch, however the editor/command line would not work as I was not authorized. Only after running the authorization does it give the instant crash seen here.
--------------------------------------------------------------------------------
Segmentation violation detected at 2025-08-29 11:25:19 -0500
--------------------------------------------------------------------------------
Configuration:
Crash Decoding : Disabled - No sandbox or build area path
Crash Mode : continue (default)
Default Encoding : UTF-8
Desktop Environment : Hyprland
GNU C Library : 2.42 stable
MATLAB Architecture : glnxa64
MATLAB Root : /opt/MATLAB/R2025a
MATLAB Version : 25.1.0.2973910 (R2025a) Update 1
Operating System : Linux 6.16.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 28 Aug 2025 19:49:53 +0000 x86_64
Process ID : 108462
Processor ID : x86 Family 6 Model 140 Stepping 1, GenuineIntel
Fault Count: 1
Abnormal termination:
Segmentation violation
Current Thread: 'MCR 0 interpret' id 140022774757056
Register State (from fault):
RAX = 0000000000000000 RBX = 00007f5997bfcd88
RCX = 00007f5a3da3bcc0 RDX = 00007f5a3da130c0
RSP = 00007f5997bfccf0 RBP = 00007f59951fe0e0
RSI = 0000000000001000 RDI = 0000000000000000
R8 = 00007f5a3da39f20 R9 = 00007f5a3da39fa0
R10 = 00007f5a3da10080 R11 = 00007f5a3da100e0
R12 = 0000000000000000 R13 = 00007f5997bfcd10
R14 = 00007f5997bfcd20 R15 = 0000000000000000
RIP = 00007f5995241ae8 EFL = 0000000000010246
CS = 0033 FS = 0000 GS = 0000
Stack Trace (from fault):
[ 0] 0x00007f5995241ae8 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+02366184 lc_new_job+00000216
[ 1] 0x00007f599515ccaf /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01428655
[ 2] 0x00007f599515d735 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01431349
[ 3] 0x00007f59951c70f4 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01863924
[ 4] 0x00007f599515fb56 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01440598
[ 5] 0x00007f599515e57d /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01435005
[ 6] 0x00007f599518edc0 /opt/MATLAB/R2025a/bin/glnxa64/matlab_startup_plugins/lmgrimpl/libmwlmgrimpl.so+01633728
[ 7] 0x00007f599471a437 /opt/MATLAB/R2025a/bin/glnxa64/authz/licensing/product/matlab_impl/mwlicensingproductmatlab.so+00160823
[ 8] 0x00007f5a77d3a656 /opt/MATLAB/R2025a/bin/glnxa64/factory_settings/compute/project/settings/../../../../../../bin/glnxa64/libmwservices.so+03384918 _ZN15MatlabLicensing11getInstanceEPKN4lmgr6config17LmStartPropertiesE+00002454
[ 9] 0x00007f5a7696c741 /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00841537
[ 10] 0x00007f5a7697ed3d /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00916797
[ 11] 0x00007f5a7695b1da /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00770522
[ 12] 0x00007f5a7695b69d /opt/MATLAB/R2025a/bin/glnxa64/libmwmcr.so+00771741
[ 13] 0x00007f5a8d2dbb17 /opt/MATLAB/R2025a/bin/glnxa64/libmwboost_thread.so.1.81.0+00043799
[ 14] 0x00007f5a8d8969cb /usr/lib/libc.so.6+00616907
[ 15] 0x00007f5a8d91aa0c /usr/lib/libc.so.6+01157644
Pinned Comments
vitaliikuzhdin commented on 2025-07-16 13:12 (UTC) (edited on 2025-08-05 20:05 (UTC) by vitaliikuzhdin)
TODO:
Figure out the users and permissions. Currently,
/opt/MATLAB/${_release}
has777
permissions, which is obviously undesired. It might be better to create a user group and require users to manually add themselves to it for security reasons.Improve the installer. For example, the current inotify watcher spams stdout and does not account for the end of the download/installation or the width of the terminal, which results in flaky output.
Figure out the dependencies. The list of Debian/RHEL dependencies is public, but it includes some seemingly unneeded packages. This might be because they are required by dependent products/add-ons. Additionally, the current logic for removing bundled dependencies should probably be rewritten. Maintaining an exhaustive list for a single release is very difficult, and these components change without notice. Moreover, the current approach may go against the Arch KISS philosophy. Ideally, we should remove only the problematic components like Qt, XCB,
libtiff
,gcc-libs
,fontconfig
, etc.Add auto-discovery for packages written for MATLAB. My plan was to use
/usr/lib/MATLAB/${_release}
for release-specific modules and/usr/lib/MATLAB/common
for shared (mostly architecture-independent) packages. However, load order matters, and "common" modules need to specify which releases they are compatible with. This means we need to implement our own logic for discovering and loading these, likely via hooks, shell scripts, and configuration files (perhaps TOML could work?).Fix the Python components.
python-matlabengine
does install the Python components built against the version of Python shipped by Arch. However, some proprietary CPython components are not included and are built against ancient Python versions. This likely requires version spoofing or some alternative approach.Write and upload packages for previous MATLAB releases. It is entirely possible to have multiple releases installed simultaneously. I have a few of these packages myself, but they are drafts and not suitable for upload to the AUR.
Write and upload packages for MATLAB-dependent add-ons and products. When installing MATLAB required user intervention for source access, it was acceptable to break reproducibility and manually specify required products for installation. Now that we use MPM, it would be better to separate products into individual packages. These packages would install themselves and their dependencies into a specific location, then use
appdata
to install only the component's files. The problem is that MATLAB often includes conflicting files that need to be combined or overwritten. Obviously, we can't allow that, so a hook must be implemented to, for example, combine*.combine@matlab-simulink
and replace*.replace@matlab-documentation
files with backups. Needless to say, this is challenging to implement, so the previous approach (having users specify the product list) might still be preferred.Write and upload the
matlab-runtime
package. I have a draft, but the problem with this package is that it installs the runtime for every available product. Ideally, for source-built packages, we would want tomakedepend
onmatlab-$product
anddepend
onmatlab-$product-runtime
. However, this is not possible without splitting the runtime packages, which poses the challenges described above. I’ll try my best to revisit this sometime later.vitaliikuzhdin commented on 2025-07-16 12:55 (UTC)
@aoneko, @Reexys, please read the post-installation instructions. If you've lost them, you can find the same information here.