-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
segfault with Matlab 2022a on Windows #200
Comments
I can confirm the same issue with MATLAB 2022a |
Me too. Is this problem solved? |
Same issue. env
test script using Libdl
## set MATLAB `matlab_libpath`.
## `julia -e "using MATLAB; print(MATLAB.matlab_libpath)"`
push!(DL_LOAD_PATH, raw"D:\dev\MATLAB\R2022a\bin\win64")
Libdl.dlopen(("libeng"), Libdl.RTLD_GLOBAL)
ccall((:engOpen, "libeng"), Ptr{Cvoid}, (Cstring,), C_NULL)
# Silence crashed debugwith windbg full dll load log
And Need to go deeper. Using C++#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include "engine.h"
#include <matrix.h>
int PASCAL WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpszCmdLine,
int nCmdShow)
{
Engine *ep;
if (!(ep = engOpen(NULL))) {
exit(-1);
}
engClose(ep);
return(0);
} compile: windbg windbg dll load log
Here's another guess: it looks like the C++ version throws a lot of exceptions, but they're all ignored. |
@inkydragon thanks for that in depth debug script. |
I have the same problem on Linux and 2022b. Any news? |
I tried Matlab R2023b + Julia 1.10.0 still crashes quietly. If that's the case, then perhaps the only way to get around this on Windows is to make a COM call. |
The crashing behavior I'm experiencing seems to be reproduced by this load and call of libeng: using Libdl
libeng = Libdl.dlopen(raw"C:\Program Files\MATLAB\R2024a\bin\win64\libeng", Libdl.RTLD_GLOBAL)
engopen = Libdl.dlsym(libeng, :engOpen)
ep = ccall(engopen, Ptr{Cvoid}, (Ptr{UInt8},), C_NULL) So there is probably nothing with MATLAB.jl that we need to worry about. It looks like there is a Here are two workarounds that @topolarity and I found that seem to confirm that this is a dll search problem: Workaround 1using Libdl
cd(raw"C:\Program Files\MATLAB\R2024a\bin\win64")
libeng = Libdl.dlopen(raw"C:\Program Files\MATLAB\R2024a\bin\win64\libeng", Libdl.RTLD_GLOBAL)
engopen = Libdl.dlsym(libeng, :engOpen)
ep = ccall(engopen, Ptr{Cvoid}, (Ptr{UInt8},), C_NULL) This workaround relies on current working directory. See this search order documentation: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#search-order-for-unpackaged-apps
Workaround 2using Libdl
LOAD_LIBRARY_SEARCH_DEFAULT_DIRS = 0x00001000
ccall(:SetDefaultDllDirectories, Bool, (Clong,), LOAD_LIBRARY_SEARCH_DEFAULT_DIRS )
path = raw"C:\Program Files\MATLAB\R2024a\bin\win64"
ccall(:AddDllDirectory, Ptr{Cvoid}, (Cwstring,), path)
# Now finish MWE
libeng = Libdl.dlopen(raw"C:\Program Files\MATLAB\R2024a\bin\win64\libeng", Libdl.RTLD_GLOBAL)
engopen = Libdl.dlsym(libeng, :engOpen)
ep = ccall(engopen, Ptr{Cvoid}, (Ptr{UInt8},), C_NULL) This changes the default search behavior for the whole process. That fixes the specific LoadLibraryW call that happens within libeng.dll but unfortunately this is incompatible with the behavior expected by Julia for julia> using SuiteSparse
ERROR: InitError: could not load library "libamd.dll"
The parameter is incorrect. |
For reference, the call that fails is this one: https://github.com/CppMicroServices/CppMicroServices/blob/899530e5b6929c90479b1b6040d2a530776fc8a4/framework/src/util/SharedLibrary.cpp#L114 The "segfault" that's reported here is just the |
The right workaround is probably to add the MATLAB libpath to |
Unable to start the engine due to an instantaneous segfault when attempting to launch the engine.
The text was updated successfully, but these errors were encountered: