TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The following code leads to an endless loop. pdflatex is at 100% CPU and the log is constantly increasing with number counted upwards.

\vrule height 210mm
share|improve this question
I get normal output in both cases (without commenting end-of-lines). Same version of mdframed. – egreg Feb 2 '12 at 21:06
Maybe try to get the latest version of l3kernel and its brothers? – yo' Feb 2 '12 at 21:24
I have done your homework, Matthias ;) (... and made a MWE) – topskip Feb 4 '12 at 18:08
A solution to the answer: you should buy a CRAY computer, a CRAY is the only computer that runs an endless loop in just 4 hours... – topskip Feb 4 '12 at 18:18
In cases like this it's very useful to run LaTeX from a terminal, rather than from the front-end; the behavior is clearly due to trying to fit an object which is bigger than the page in height. Running from the terminal would show immediately that TeX is shipping out pages after pages. – egreg Feb 4 '12 at 18:30
up vote 4 down vote accepted

Based on the example of Patrick, I can provide an answer.

The material of the environment mdframed is saved in a simple \vbox. Based on computed lengths related to the text height, the box will be split by \vsplit. Your material can't be split, so you run into an endless loop because mdframed repeats the splitting algorithm. Up to now there is no check for such situations.

In order to avoid the endless loop you can use the option nobreak. However the result is a blank page and the output itself.

 \vrule height 250mm
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.