# Certain comment contents break LaTeX rendering for the whole page

I commented just some minutes ago on this question, and every post in math.SE returned a [Math Processing Error]. Not only for me, but for every other user.

What is going on with this question. I can't see any formulas only here, but not in other questions! – Norbert 26 mins ago

There is a problem with the LaTeX-rendering, but I can see your edit. BTW, regarding Taylor expansion I think it is more common thing with $O(x^3)$ and $f∈C^3$ for Taylor application. – AD. 24 mins ago

When I deleted to comment, as suggested by Fabian, everything went back to normal. The code was long, but as I recall, correct:

$\mathop {\lim }\limits_{x \to 0} \left( {1 + x + \frac{{f\left( x \right)}}{x}} \right) = \mathop {\lim }\limits_{x \to 0} \left( {{e^{3x}}} \right)$


I usually use MathType when coding very long equations, so maybe it was the translation the software used that did something. More precisely, MathType translates its templates into $\TeX$ $\to$ $AMS\TeX$, which is what I use. There are other options, such as

1. $AMS\LaTeX$
2. $\LaTeX \text{ }2.09$ and later
3. Plain $\TeX$

How can I be sure that this won't happen again? (Mostly because if I hadn't been online, you'd have to ask a mod to delete the comment, or something of the sort, which'd have been quite a problem.

I have figured out both the problem with the \limits macro and with the failure to process the rest of the mathematics that it caused. It is basically as I outlined in my comment on @Zev's answer. The TeX input jax had an internal failure (it tried to use a null pointer), and that was trapped by MathJax as it was supposed to be. But it also meant that the internal form for that equation was not available, and when the HTML-CSS (or SVG or NativeMML) output jax went to typeset that internal form, it wasn't there, so there was another null pointer problem.

Each output jax makes an initial pass through all the math in order to determine the surrounding font size (this is done before any math is actually typeset in order to improve IE performance). It was on that pass that the output jax failed. That was also trapped by MathJax, but it meant that the output jax only had determined the sizes for some of the math on the page, and when it went to typeset the rest of the math, that size data was unavailable, which caused the "[Math Processing Error]" messages for those expressions.

The earlier expressions were actually typeset, but because MathJax displays the mathematics in blocks of 50 expressions (again for performance reasons), the earlier math was not displayed, leaving only the previews in place, not the typeset math.

The upshot is that there were a bunch of places where the output jax had to check that the input had actually been processed where it wasn't doing so. I have fixed this in all three output jax, but it will not appear on the CDN until the next release. We are expecting to make a v2.0a release in the near future to take care of a bunch of bug fixes of this sort.

Thanks for your patience, and for reporting the issue.

• Thank you for the info. What translating code do you reccomend when using MathTyoe?
– Pedro Mod
Apr 11, 2012 at 16:48
• I'm sorry, but I'm not sure I understand the question. I assume you mean "MathType"? Well, I've never actually used it myself, so I'm not sure the possibilities are. But it should be able to produce LaTeX format, so that should work. Are you having problems with that? Apr 11, 2012 at 17:50
• Not really, but maybe MathJax'd work better with one of those. Each option has some differences, such as \frac{}{} versus {}\over{}
– Pedro Mod
Apr 11, 2012 at 18:09
• Either form is fine (though it is really better expressed as {...\over...} I think.) Apr 11, 2012 at 20:45
• It's difficult for us to claim that "bugs" in MathJax are ours. So it's awesome that you're here assisting with these bug reports, because otherwise it'd be a lot more difficult for everyone to work through to a solution. Thank you! Apr 23, 2012 at 4:34
• @Jeff: Absolutely, bugs in MathJax are mine, not yours, and I am glad to have such an excellent community that is using MathJax and reporting the issues in an environment that makes that easy to do. I have really enjoyed working with you all on this. Because there are some complex interactions between MathJax and the preview code, it is not always easy to tell where the problems lie, but I am glad to lend my understanding of MathJax to help resolve the issues. It makes MathJax better in the end as well, and so we both benefit. Apr 23, 2012 at 11:41

The actual code was

$\mathop {\lim }\limits_{x \to 0} \left(1 + x + \frac{{f\left( x \right)}}{x} \right)=\mathop {\lim }\left( \limits_{x \to 0} {e^{3x}} \right)$


The problem was that the second \limits command was misplaced.

• And that crashed the page?
– Pedro Mod
Apr 10, 2012 at 22:02
• It would seem so. I certainly still think it's a problem that MathJax would fail so spectacularly for such a minor TeX error - at most it seems like it ought to be contained to the comment - but I don't know anything about MathJax's internal workings, perhaps it is simply a necessary part of how it renders. Apr 10, 2012 at 22:04
• OK. Actually, what I did was misplace \left( now that I see it.
– Pedro Mod
Apr 10, 2012 at 22:05
• Right, i.e. equivalently the \left( and \limits were transposed. Apr 10, 2012 at 22:06
• Fermat's theorem: $x^n + y^n = z^n$. Offending math: $\mathop {\lim }\limits_{x \to 0} \left(1 + x + \frac{{f\left( x \right)}}{x} \right)=\mathop {\lim }\left( \limits_{x \to 0} {e^{3x}} \right)$. Fermat's theorem again: $x^n + y^n = z^n$. Apr 10, 2012 at 22:07
• I am looking into the problem and will get back to you when I know better what happened. Apr 10, 2012 at 22:20
• OK, found it. MathJax is referencing a non-existent object in this case, and that causes the TeX input processor to produce an invalid internal structure, and the output processor gets hung up on that and produces the "Math Processing errors" for all subsequent math. Because all the output is scanned first by the output processor, and the crash occurs on the initial pass, that also means that none of the previous output is fully processed either. The TeX input error is easily fixed. The cascade is going to take a little more study. Apr 10, 2012 at 22:47
• @Davide: Thank you, as always, for your expertise and help! Apr 11, 2012 at 0:51
• You are very welcome. It is a pleasure to help out the StackExchange community. Apr 11, 2012 at 16:11

MathJax v2.1 should resolve this issue. Since math.SE is now using the beta version of MathJax v2.1, so you should see the correct rendering these characters now (both the empty sets and the setminus issues should be fixed). Please let me know if that is not the case.

Note that if you keep your browser open continually, you may need to empty the cache and reload the page (or perhaps even restart the browser) to get the new copy of MathJax. (MathJax's About box should tell you which version you are getting; make sure all the files in the list show v2.1).

See MathJax 2.1 beta for more details on the changes in MathJax v2.1.
{"ft_lang_label":"__label__en","ft_lang_prob":0.9522192,"math_prob":0.8439669,"size":1279,"snap":"2022-40-2023-06","text_gpt3_token_len":354,"char_repetition_ratio":0.08,"word_repetition_ratio":0.009049774,"special_character_ratio":0.28381547,"punctuation_ratio":0.117870726,"nsfw_num_words":0,"has_unicode_error":false,"math_prob_llama3":0.98108375,"pos_list":[0],"im_url_duplicate_count":[null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2022-09-27T23:34:52Z\",\"WARC-Record-ID\":\"<urn:uuid:20afe8e6-b4f0-47d3-a2e5-934cd9b47881>\",\"Content-Length\":\"144155\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:45eaa41e-48c2-4109-b2db-e97d384eabbd>\",\"WARC-Concurrent-To\":\"<urn:uuid:a4a5658d-4de1-4aee-93be-63ab6024f5ce>\",\"WARC-IP-Address\":\"151.101.65.69\",\"WARC-Target-URI\":\"https://math.meta.stackexchange.com/questions/3942/certain-comment-contents-break-latex-rendering-for-the-whole-page\",\"WARC-Payload-Digest\":\"sha1:2DCZ6Y5LDOWQ7UCOE3XNWNFVNAYYQRBP\",\"WARC-Block-Digest\":\"sha1:W65VK3Z2TVEMDMWWA2RCDF2OO4L5NAHV\",\"WARC-Identified-Payload-Type\":\"text/html\",\"warc_filename\":\"/cc_download/warc_2022/CC-MAIN-2022-40/CC-MAIN-2022-40_segments_1664030335059.31_warc_CC-MAIN-20220927225413-20220928015413-00260.warc.gz\"}"}