Load_stimulus issue

Hi Chris,

We are having an issue with an experiment in which we are presenting images from a local directory. The experiment loads fine, but when load_stimulus is called the program crashes. The strange part is that this experiment worked fine a few months ago, and as far as we know nothing has changed about MWorks, the OS, etc.

I’ve attached a copy of the crash error and the xml- the error occurs on when these lines are executed:

Do you have any sense of what the issue might be?

Thanks,
Lindsey.

Attachments:

Hi Lindsey,

It looks like the crash occurs not in load_stimulus but rather during update_stimulus_display (possibly immediately after the load_stimulus, although I can’t tell from the crash log). It also looks like part of the load is happening asynchronously and hasn’t completed yet. This may be the cause of the crash, which occurs inside the graphics driver.

Would it be possible to add a short wait (maybe 100ms) right after the load_stimulus actions? That should give the asynchronous part of the load (which MWorks unfortunately has no knowledge of or control over) time to finish.

Alternatively, I suspect this wouldn’t be an issue with a recent nightly build. MWorks’ stimulus rendering code has been modernized and basically completely rewritten since the build you’re using, and it wouldn’t even use the driver that’s triggering this crash.

Cheers,
Chris

Hi Chris,
We updated to the nightly and added the wait statement. Now there is a
crash after the first trial.
I’ve attached the Apple and Console crash reports.
Thanks
Lindsey.

Attachments:

Also- this seems to be a more general issue as we get the same crash when
running other experiments that do not load images.
Lindsey.

Hi Chris,
Looks like there is an issue with Matlab communication. We ensured that
the matlab setup is correct (using these
https://mworks.tenderapp.com/kb/data-analysis/setup-for-using-matlab
instructions), but it did not solve the issue.
This is the error report that we got when using the terminal query:

hullglick5:/ hullglick$ /Applications/MWClient.app/Contents/MacOS/MWClient
2021-12-21 12:41:44.287 MWClient[2955:9428162] log file path:
/Users/hullglick/Library/Logs/MWorks/20211221_124144287.log
dyld: lazy symbol binding failed: Symbol not found: _mxCreateStructArray_800
Referenced from: /Library/Application
Support/MWorks/Plugins/Client/MWorksMATLABWindow.bundle/Contents/MacOS/MWorksMATLABWindow
Expected in: /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib

dyld: Symbol not found: _mxCreateStructArray_800
Referenced from: /Library/Application
Support/MWorks/Plugins/Client/MWorksMATLABWindow.bundle/Contents/MacOS/MWorksMATLABWindow
Expected in: /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib

Abort trap: 6

Lindsey.

Did you recompile your LabJack plugin against the nightly build?

Yes

OK. Is it just MWClient crashing now, or does MWServer crash, too?

Regarding MATLAB, MWorks’ MATLAB tools and MWClient’s MATLAB window are currently built against MATLAB R2018b. With the older MWorks build you were using, the MATLAB stuff was built against R2017b. It looks like you’re using MATLAB R2014b, so I’m surprised that things worked even with the older build. Switching to R2018b or later should fix things.

Chris

Yes- it is mwServer that crashes and mwClient stays open (though it is
“frozen” and needs to be force quit).
We’re updating Matlab now…
Lindsey.

OK. I asked because the latest crash report you sent was for MWClient. If there’s a crash report for MWServer, can you send that, too?

Also, if it’s possible for you to provide me with the image files you’re using, I can try running the experiment myself and see if I can reproduce the crash.

Thanks,
Chris

Sorry- I had that backwards- it’s the Client that crashes not the Server.
Let’s see if the new Matlab install fixes everything. If not, I’ll send
you the images for testing.
Thanks,
Lindsey.

Updating MWorks and Matlab solved it- thanks!
Lindsey.

Great! Thanks for letting me know.

Chris

Hi Chris,
There is still one small issue: MWServer does not quit normally. You have
to “close experiment” rather than just command-Q, or it will crash and need
to be force-quit.
Thanks,
Lindsey.

Hi Lindsey,

If there’s a crash report, you can send it to me, and I’ll take a look. However, you really should explicitly close the experiment whenever possible. Some things can’t shut down properly otherwise.

FYI, I’m on vacation starting today through the end of the month. If needed, I can follow up on this in January.

Happy holidays!

Chris

Hi Chris,
Ok- we’ll close the experiment going forward- but I’ll grab an error report
next time and send it.
Also- we have a resurgence of the ehFeedback error with the new nightly.
We merged your pull request from July that should fix this- so maybe the
nightly introduces some new issue? Would be great if you could check on
this when you’re back in town.
Have a good holiday,
Lindsey.