MAJOR 25+ YEAR OLD MATLAB BUG. PLEASE, PLEASE FIX! Ctrl-C doesn't work, no way to stop a process.

It is still, after more than 25 years, not possilble to stop a running Matlab process and/or clear memory without aborting Matlab externally in many kinds of circumstances. Sorry if I sound frustrated and I genuinely don't mean to be impolite as I'm a dedicated Matlab user, but, well, I think it's pretty reasonable to be frustrated with this behavior at this point. I think that frustration is a reasonable response and a genuine expression of the user reality that I describe below. I express frustration, a frustration which I believe is shared by many users, with the sincere hope that this will get the Mathworks' attention, and that the Mathworks will take it seriously and take on a significant challenge to overcome it. Matlab is a great product, and I believe that that this would really make it much better and in alignment with modern expectations for a development environment.

Please Matlab, solve this problem. Make this a priority. I think it's very clear, and has been very clear to many users for a very, very long time (see below), that this is just not an acceptable way for Matlab to function.

Here is an example of the kind of pretty clearly unacceptable workflows that it leads to (and that I am dealing with curently, and have dealt with many times over decades).

THE MATLAB DEATH LOOP

Example:

Load a large dataset into memory, eg a very large table (eg a gigabyte).

Run some code that uses the table.

Need to make a simple change, eg change a line of code.

Attempt to re-run the code. This leads to a complete and indefinite freeze of the Matlab process.

There is no way to stop the running code or clear memory, including ctrl-c, ctrl-break, hitting stop on the editor window, etc. Not even clear.

Only viable option: externally terminate the Matlab process, eg using Activity Monitor on Mac, Task Manager on Windows or a terminal kill command. The same basic issue exists on most or all platforms as far as I'm aware. Sometimes, lose any unsaved changes to code, variables, data, settings, etc.

Start over, re-initialize everything in Matlab that was set up, do whatever processing is required to get to the point of the change (which is sometimes very time-consuming) and do it all again. Then change another line of code, and then do it again. Very, very slow and painful development workflow / way to make progress.

Matlab has many circumstances, especially involving large memory objects, where it gets stuck in some kind of memory management process indefinitely (many minutes). I have also experienced this in other circumstances that don't involve large variables but involve other processes that seem to be able to get Matlab stuck.

Commands like clear to try to start over can just lead Matlab to get stuck in some kind of memory management process indefinitely (again, many minutes). Simlarly for displaying large objects in the object/variable viewer.

There is no way to embed a 'drawnow', a hack that sometimes solves this problem for certain kinds of loops, because commands like clear, load, etc. cannot have a drawnow inserted into them.

There are ways to try to work around this issue, eg avoiding large datasets. That said, I really believe that the issue impacts many users, is really just not an acceptable way for a modern development environment to function, and that it needs to be solved directly in some way. I also believe that a solution would be possible.

I appreciate that there are issues with OS implementations, eg memory management, that make this a challenge. That said, I'm quite sure that there is a better option that the brilliant minds at the Mathworks can come up with than the MATLAB DEATH LOOP. This has been a problem with Matlab for multiple decades at this point.

For me, as a long-term and dedicated Matlab user, it's been by far the biggest problem with Matlab. There is certainly no other IDE/development environment that I work in where I have to do this.

This has been a widely-known problem that impacts many users. Here's an example of a post that has had 1088 views in the last month, and that was from more than a decade ago:

https://www.mathworks.com/matlabcentral/answers/10585-can-i-stop-matlab-when-it-s-being-busy?s_tid=srchtitle

Please consider making this a priority and coming up with a solution to it.

Thank you

[John D'Errico]

I've been wanting to see world peace for many, many years now. Yet, despite the efforts of so many brilliant people, they have not found success. Some problems have no simple solution, despite our desperate desires.

The point being, make sure your code will do what you want, running properly with no need for interruption, so you can avoid having to interrupt it.

In my case, I run a script every night for the last few weeks, running MATLAB flat out all night long. I insure I never lose more than at most an hour's worth of CPU time if it has a problem, because I have it do a save of the current state periodically. And, yes I do know that if I need to interrupt MATLAB in the middle of a call, it will not want to talk to me until the code that was called is done. That could take several minutes, or as much as several hours in some cases. So I accept it, and avoid the need. In my case, I display a prediction of when the current process will be done, as I can predict that accurately, so I know exactly when I CAN safely interrupt MATLAB if I need to do so the next morning.

Plan to work WITH MATLAB, not against it as an adversary.

[CdC]

Thanks John. Appreciate the suggestions for workarounds.

I remain hopeful that as with other IDE's, if Mathworls sets their minds to this as a priority, this is a solvable problem. It is not mine to try to solve the problem for them, but separating processes seems a pretty good starting point.

While I appreciate your point that wanting something doesn't make it possible, having worked on world peace in the past, I believe that process/memory management is a meaninfully more tractable challenge! I'd really like to see Matlab take it up, and I think it'd benefit many (including you, by the sounds of it). I also hope that the effort to create a solution at the IDE level would take less effort than the effort being spent over many years by countless Matlab users trying to work around it, as you are.

Thanks again for your thoughts.

Answer 1

[Walter Roberson]

| appreciate that there are issues with OS implementations, eg memory management, that make this a challenge. That said, I'm quite sure that there is a better option that the brilliant minds at the Mathworks can come up with than the MATLAB DEATH LOOP.

Unfortunately:

• the C programming language does not define any signal happening
• intel Fortran does not define signal handling on Windows
• gnu Fortran has quite limited signal handling that mostly generates a core dump
• C++ does define signal handling. But the functions that can be called are fairly limited; https://en.cppreference.com/w/cpp/utility/program/signal -- notice that you cannot call library functions such as closing a file
• if MATLAB does not know the implementation language of DLL or mex that it is calling into, it must assume that the compilation language does not support signal handling
• you cannot impose meaningful signal handling from outside a function

Basically, MATLAB has no way to interrupt the great majority of external operations -- no way, for example, to interrupt when calculations are executing in MKL or LAPACK.

No way, that is, other than to run the operation in a different process or different thread and cancel the thread.

On Windows, thread termination is TerminateThread https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminatethread which Microsoft documents as

TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:

• If the target thread owns a critical section, the critical section will not be released.
• If the target thread is allocating memory from the heap, the heap lock will not be released.
• If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
• If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

But of course, when calling into external functions or the operating system, "only if you know exactly what the target thread is doing" is decidedly not the case.

What can you do? Well, if you have code that might potentially lock up, you could make efforts to move into into a background thread pool (recent MATLAB) or into a parallel worker pool (Parallel Computing Toolbox), as it is possible to cancel such workers. However, in the case of background threads, I suspect that the cancel does not take effect until the task it is executing returns to MATLAB.

[CdC]

Thank you for your thoughts. I'd like to still hope that this is a solvable problem despite the challenges. Separating into different processes is how other IDE's handle it as far as I understand.

Can you share a bit more about how the background thread pool approach would solve the problem? I looked at the documentation here:

https://www.mathworks.com/help/parallel-computing/parpool.html

An example illustrating how to use this to solve the Matlab Death Loop might be helpful to many people, certainly me.

Thanks again.

[Walter Roberson]

https://www.mathworks.com/help/matlab/ref/parallel.future.cancel.html