# This code crashes the FrontEnd - can I remove anything else?

Bug present in version 11.0.0

Thank you for contacting Wolfram Technical Support and for taking the time to report this issue. I have forwarded it to our development team.

I want to file a report with the following (stack-overflow provoking) code that crashes the FrontEnd (IMO, the kernel/FrontEnd should be stable enough to not crash with such faulty code).

Format[x_c] := RawBoxes@RowBox@{Riffle[MakeBoxes /@ f[x], ","]}
c[]


I have reduced it to this far, but maybe someone can find something more that is not needed to produce the crash.

Interestingly, it does not crash if I use List instead of f.

• For me, this crashes the kernel (not the front end) in 11.0.0 for Linux x86 (64-bit) (July 28, 2016) and "10.4.1 for Linux x86 (64-bit) (April 11, 2016)" – mikado Sep 12 '16 at 20:25
• I suggest that you don't need to refine the problem any further to have a worthwhile bug report. – mikado Sep 12 '16 at 20:26
• If you are looking for a simple example, try (Format[test] := MakeBoxes[test]); test – ilian Sep 12 '16 at 20:39
• What is this code trying to accomplish? I mean, something like Block[{\$RecursionLimit = Infinity}, x = x + 1]  will certainly crash the kernel by exhausting the stack... but I'd consider the result to be self-inflicted. – ilian Sep 12 '16 at 21:52
• @ilian It's self-inflicted, that's true. It's the result of a typo. But I think its nice not to lose unsaved progress to notebooks because of things like that. The kernel crashing usually doesn't bother the FrontEnd too much. But even there, IMO the interpreter should stop before chaos strikes and at least print an error. A JVM will rarely crash unbeknownst to it. – masterxilo Sep 12 '16 at 21:58

Thank you for bringing this to our attention. I've done a preliminary investigation. On Unix only the kernel crashes, on Windows the FE crashes (or, more accurately, the FE crashes before the kernel has a chance to crash). Here are a few observations about the issue and your code.

1) You're mixing the Format world and the box world. If you want the kind of control you get from the box world, use MakeBoxes rules. They don't leak (when written properly) and are much less likely to fall into infinite recursion like this. Also, Format rules apply in all forms, not just StandardForm/TraditionalForm. So you end up getting examples like the following, which are probably not what you want.

In[2]:= Format[f] := RawBoxes@RowBox[{"foo", "+", "bar"}]
In[3]:= ToString[f]
Out[3]= "RawBoxes[RowBox[{foo, +, bar}]]"


2) It's not hard to understand why you get different behavior for f and List. When you have List, the Riffle evaluates successfully, so you're only recursing on the MakeBoxes (similar to Ilian's example). With f, you keep getting a larger tower of unevaluated Riffle's.

3) MakeBoxes /@ f[x] is evaluation leak 101, because Map isn't Hold-anything, so the sort of evaluation protection you get from is lost because f[x] is evaluated prior to entering the map.

4) You don't want the braces in your example. Riffle would return a list, so the outer list is wrong. Indeed, without those braces the FrontEnd doesn't crash--that's a clue.