unexpected crashes

[maartenvd]

great that this project is still being updated! I just tried out with the newest release candidate for julia which again exports options, so the build script works.

I tried to use this package in the past to write bindings for matlab against a julia optimization library (I have attached a toy version testmex.zip ). I want to call a julia function from matlab, and supply it with function handles. Then in turn, the julia function will call those matlab function handles with data.

This works, as you can see. However, if you run it often enough (matlab 2018a, ubuntu linux), I get an unexpected crash. The fact that this is sporadic makes me suspect the julia garbage collector, is there something to be mindful about when using mex?

I've tried debugging this but I'm hopelessly out of my depth, I never succesfully attached gdb to the matlab process.

[taylormcd]

I've also had occasionally crashing when using the call_matlab function. I don't know if this is occurs due to a limitation imposed on MEX files by MATLAB or due to improper data handling on the Julia side and I haven't been able to pinpoint the root cause of this issue. For not being very large, this package is quite complicated since it deals with two higher level languages and their respective lower level interfaces. I've often thought it would be nice to have someone who is an expert in MEX files and/or embedding Julia take a look at this package. I don't consider myself to be an expert in either.

As a workaround, try to replace all instances of call_matlab with equivalent calls to MATLAB using MATLAB.jl. The downside of this approach is that it limits the code you can call to what is available to the MATLAB engine session created by MATLAB.jl. Hopefully this works for your application.

[maartenvd]

Well the attached project is primarily a test on the stability of mex.jl, on a fork that was made quite a while ago. Honestly if the issue is only in the call_matlab function, then everything I really need for my actual purposes already works! I will experiment a bit with some tests that do not work with call_matlab.

Though if the issue is really only there, and probably being a GC issue - seeing how sporadic the crashes are - I can even try to create a minimal working(crashing) example. I won't have time for the coming 3 weeks, but if I have anything I will try to propose a fix or at the very least post it somewhere hereabouts!

In any case thanks a lot for updates to this package!

[maartenvd]

ok the easiest crash I can find is:

jl.eval('invalidsyntax()')
jl.eval('GC.gc()')

this is perhaps not very important, but pretty much any error you make in julia will later on lead to an unexpected crash when garbage collection triggers.

A totally unrelated minimal example is this:

function test(args::Vector{MATLAB.MxArray})
    out = jvalue(args[3])
    temp = args[2];
    for i in 1:out
        temp = call_matlab(1,"feval",[args[1],temp])
        GC.gc()
    end

    temp
end

jl.mex('test',@(x) x*x,rand(5),1)

will run without any problems, even when called multiple times. However this

jl.mex('test',@(x) x*x,rand(5),2)

immediately comes crumbling to the ground.

[taylormcd]

It's actually not that unrelated because the error handling uses call_matlab. I'll look into it. It's good to know that it is related to the Julia garbage collector. Thanks for finding that.

On Tue, Nov 23, 2021, 1:52 AM maartenvd @.***> wrote:

ok the easiest crash I can find is:

jl.eval('invalidsyntax()') jl.eval('GC.gc()')

this is perhaps not very important, but pretty much any error you make in julia will later on lead to an unexpected crash when garbage collection triggers.

A totally unrelated minimal example is this:

function test(args::Vector{MATLAB.MxArray}) out = jvalue(args[3]) temp = args[2]; for i in 1:out temp = call_matlab(1,"feval",[args[1],temp]) GC.gc() end

temp

end

jl.mex('test',@(x) x*x,rand(5),1)

will run without any problems, even when called multiple times. However this

jl.mex('test',@(x) x*x,rand(5),2)

immediately comes crumbling to the ground.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/byuflowlab/Mex.jl/issues/11#issuecomment-976293497, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDIQXZJYFYDFD434ECO273UNNI5FANCNFSM5HWPM54A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[maartenvd]

I feel rather silly, as the second example is actually also an error.

temp = call_matlab(1,"feval",[args[1],temp])

call_matlab will return a vector, which gets put into temp. temp then gets again given to call_matlab, which is where it goes wrong.

it should've been

temp = call_matlab(1,"feval",[args[1],temp])[1]

which works just fine?

So then, it mostly seems that julia errors in mexed calls or matlab errors in callbacks will lead to some invalid memory somewhere and then crashes later on.

[taylormcd]

I tried to dig into this, but can't figure out where the issue is. It seems to just affect the call_matlab function though. The simplest example I can find is

jleval call_matlab(1, "sin", 1.0)

Note that this function doesn't error, but this does cause a segmentation fault when MATLAB is closed (which can be seen if MATLAB is run from the terminal). Unfortunately, I don't really have the time to look into this any further.