Long-standing Crash on exiting on OSX

[imunro]

The Matlab help desk sent the following:

"Dear Ian,

I believe that the issue you are experiencing occurs, as you pointed out, due to a conflict between the c++ code and the MATLAB deployable. A segmentation violation is being thrown while closing the app and that might be because the app is trying to release resources for some object that is already deleted.

The MCR installs some signal handlers during its initialisation; one of these is 'mnFatalSignalHandler', which is catching the SIGSEGV or Segmentation Fault signal. This SIGSEGV might not be generated by the deployed MATLAB code but by the other c++ code. This exactly what the stack trace is suggesting, as there are not MATLAB specific functions being called aside from the crash handling mechanism. Hence MCR creates a MATLAB crash report even thought the crash does not originate in the deployed MATLAB code.

There are two venues to address this:

1. Restore the application's original signal handlers once the work of the deployed MATLAB code is done.

As an example, see the attached file "myaddprogram.c". Here a SIGSEGV is artificially generated by the c code but is caught by MATLAB's signal handler. The workaround mentioned above is applied in "myaddprogram_workaround.c" and the result is that no MATLAB crash report is generated. It has to be noted that the SIGSEGV is generated after restoring the original signal handler.

2. Disabling MATLAB's crash handling completely by setting the environment variable 'MW_CRASH_MODE ' to 'none'.

This would not let MCR install its signal handlers and the applications original signal handlers will catch no mater where the crash originates in the code. Note that in this case the genuine crashes originating in MATLAB code will also be handled by the application's signal handler. If the application does not install any signal handlers then the application will terminate in a manner configured in the system's settings.

I hope this information helps you.

Sincerely,

Ignacio Funke MathWorks Technical Support Department" myadd.zip

[imunro]

I have just noticed that the File->Quit menu item shuts down cleanly. So a simpler solution may be available.

[imunro]

@seanwarren This doesn't need fixing for 5.0.2. We've lived with it for ages but now I've started to investigate it's really annoying me. It looks like the c++ is throwing errors when it shuts down, either not deleting things or trying to delete stuff that hasn't been created yet. (at a guess vis studio has some non-standard garbage collection so we don't see it on Windows) Is there a "close' function in the dll-interface that needs to be called on shutdown?

[seanwarren]

@imunro - how do you reproduce this? using the red close button?

[imunro]

Yes File->Quit seems to be generally better behaved. Although if you close straight away, without doing anything involving the c++ it's File->Quit that crashes and red-close that works ok. Unless you happen to know what this is, leave it with me for a bit I'm talking to the Matlab helpdesk & trying things. See https://github.com/flimfit/FLIMfit/pull/319

[imunro]

@seanwarren I'm trying to debug this. I'm a bit baffled where the .dylibs have gone now in the FLIMfit.app package. I've never really worked out what dylibundler does. The dylibpath is set to point to FLIMfit5.0.2.app/Contents/Resources but I can't see the dylibs. What are they bundled into now?

[seanwarren]

@imunro, the libraries are passed through dylibbundler before being passed to mcc to be compiled by Matlab. I think Matlab then hides these in the actual executable. I guess we will need to bundle with debug libraries to test though. I will be at Imperial on Monday, perhaps we could have a look then if you're in?

[imunro]

Hi Sean I'll be in. It'll be the usual chaos though. I look forward to seeing you. BTW I just tried launching the actual FLIMfit code, buried deep in our .app from the command line & it looks happy so I'm now suspecting possibly Platypus.