Latex build with 2 figures / 1 list hangs forever (100% CPU load)

[mulmschneider]

Describe the bug The .rst file below deterministically causes pdflatex to hang forever with 100 percent CPU load. I'm no LaTeX expert, so I'm unsure how to debug this further.

To Reproduce

.. Image creation: `convert -size 800x10 canvas:black black.png`
.. figure:: black.png
    :align: left

a

a
 - a

.. figure:: black.png
    :align: left
    :width: 80%

Build:

convert -size 800x10 canvas:black black.png
sphinx-build -b latex . _build/
sh -c "cd _build; make"

Environment info I'm using a docker image with the following Dockerfile:

 FROM alpine:latest                                                                                                                                                                                             
 RUN apk add -U texlive python3 make texmf-dist-latexextra

Versions:

# pdflatex --version
pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019/Alpine Linux)
kpathsea version 6.3.1
Copyright 2019 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.37; using libpng 1.6.37
Compiled with zlib 1.2.11; using zlib 1.2.11
Compiled with poppler version 0.82.0

# sphinx-build --version
sphinx-build 2.3.1

[tk0miya]

@jfbu Could you check this please?

[jfbu]

This is a bug of Sphinx \sphinxincludegraphics LaTeX macro (or at least a bad interaction with wrapfig).

Thanks for reporting, sorry for inconvenience and being late. I can not handle it immediately but will asap.

[jfbu]

Well this looks like a rather complicated thing where a core LaTeX graphics macro falls into an infinite loop (this core LaTeX macro arguably has a bug here because it does not guard against division by zero at this location), and at this time I am not sure if \sphinxincludegraphics alone is to blame (have to check more), except that it reveals the problem which is mainly induced by wrapfig dealings. That there is something fishy going on is illustrated by the fact that the bug shows only if LaTeX file contains this

\end{description}
\begin{wrapfigure}{l}{0.800\linewidth}

instead of this

\end{description}

\begin{wrapfigure}{l}{0.800\linewidth}

where the sole difference is the added empty line and there is no \sphinxincludegraphics in sight!

@tk0miya I think we can fix this bug simply by making sure wrapfigure environment is always inserted after a blank line and never follows immediately a list environment in LaTeX file.

I can not make PR in immediate future, and I will devote some time when I can to go to the root cause of this (I noticed this seems to be related to \linewidth being unexpectedly negative (-10pt) in the situation where the wrapfig environment follows immediately the \end{description}.) which is perhaps more in LaTeX per se than in Sphinx own LaTeX macros.

[tk0miya]

Thank you for detailed investigation! I'll make a PR instead of you sooner. I believe it's okay to insert a blank line before wrapfigure because figure node is a block level node.

[tk0miya]

Fixed by #7092. Thank you for reporting!