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

10 views (last 30 days)
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).
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:
Please consider making this a priority and coming up with a solution to it.
Thank you
CdC on 30 Sep 2022
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.

Sign in to comment.

Answers (1)

Walter Roberson
Walter Roberson on 30 Sep 2022
| 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.
  • 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; -- 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 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.

Sign in to comment.


Find more on Startup and Shutdown in Help Center and File Exchange




Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by