My Mathematica front end will freeze occasionally for unreproducible reasons. This seems mostly associated with long (> 1 hour) computations, although not exclusively. If I click on the Mathematica icon from the OSX dock, or alt-tab to it, none of the notebooks become viewable. The OSX activity monitor correctly identifies the front end process "Mathematica" as "Not responding".

In the past if this happened I was forced to kill the front end process, which wiped out any unsaved notebooks. However, I have recently figured out that I can usually preserve the front end, and the notebook data, by just killing the WolframKernel tasks instead. I generally have multiple kernels running, which are indistinguishable within the activity monitor, and I basically have to kill them randomly one at a time until the front end starts responding again. I still lose the kernel, but I no longer lose the front end and the notebook data.

What's going on? Isn't the point having a separate front end process that it can survive crashes and freezing of the kernels?

I run version 10.3.00 on OSX 10.11.2.

Update: I'm still having issues with this. Recently, the kernel computations stopped in the sense that the CPU usage went almost to zero. However, the grey circle "running" indicator in the dock still shows, and the front end remains unresponsive. Killing the problem kernel resurrected the front end and, interestingly, caused the other kernels to resume computation (i.e., their CPU usage went back to 100%). The system memory utilization was low throughout.

Update 2: I can now almost always identify the problem kernel as the one that has low CPU usage (~10%) while the other wolfram kernels have negligible (0%-2%). Interestingly, it's recently happened twice that the problem kernel was not running a computation, but just idling (i.e., associated with a notebook not doing anything). Once it was force quit, the other kernels resumed (~97% CPU). Also, I have upgraded to with no noticeable change.

Update 3: I have now had this issue with dynamic objects disabled, so that doesn't appear to be the root cause. Interestingly, I have twice now "caught" it in the middle of the freezing process, in this sense: The front end suddenly stops responding (spinning beach ball), but at least some of the background computations remain at max CPU. This continues for a while but, one by one, the kernels fall to idle, abruptly dropping from max to min CPU over a short time (1-5 seconds) and then staying there. All of the kernels seem to come to idle within a couple minutes of the front end freezing. Then, if I kill the problem kernel, the remaining kernels resume their computations as before.

  • 5
    $\begingroup$ I have had the same experience. I cannot provide an answer from knowledge, but I assume that the Front End is waiting for the Kernel to do something, and that killing the Kernel causes the Front End to break the connection and stop waiting. $\endgroup$
    – Mr.Wizard
    Jun 1, 2016 at 23:04
  • 3
    $\begingroup$ Do you use Dynamic elements in your Notebook? $\endgroup$ Jun 2, 2016 at 6:05
  • 2
    $\begingroup$ Another possible source of such FrontEnd freezing is that your code contains something like Rasterize, Export etc. - any function which requires FrontEnd. Such functions usually freeze the FrontEnd during evaluation and (may be unexpectedly but quite logical) killing the Kernel unfreezes the FrontEnd in such situations. $\endgroup$ Jun 2, 2016 at 13:47
  • 3
    $\begingroup$ May be it is worth to mention that I always use PrintTemporary for creating Dynamic objects: it auto-deletes the Dynamic element when evaluation of the current Cell is finished. $\endgroup$ Jun 2, 2016 at 13:57
  • 2
    $\begingroup$ Dynamic stuff (which is sometimes created inadvertently – even a simple Histogram has it!) causes the front end to periodically request the kernel to interrupt what it is doing for a while and tend to another evaluation. Things can indeed go wrong with this and the front end can freeze. Sometimes I cannot identify the reason of the hang at all, but sometimes it's because the kernel is doing something that cannot be interrupted at all. One example is LibraryLink stuff you write yourself (and do not explicitly make interruptable). $\endgroup$
    – Szabolcs
    Jun 2, 2016 at 14:18


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.