WeasyPrint 0.42 gets stuck #560
Comments
|
It may be a duplicate of #557. Could you please try to reproduce with master? |
liZe
added
crash
|
Will comment again when the build for greenelab/scihub-manuscript@cfe2a05 is complete. So far not looking good (running for over 80 minutes), although its not clear yet exactly where its getting stuck. Interesting that it's not timing out after inactivity like before (that could be a Travis issue, perhaps the root cause of this backlog). Update: build has been "Running for 5 hrs 46 min 25 sec". I think we broke Travis hehe. |
|
The build finally timed out after running for 8 hours. It appears the build got stuck while running WeasyPrint. So I don't think the issue has been fixed as of ea9ffc9. |
|
Is it possible to get a HTML+CSS file generated by pandoc that makes the bug happen? |
|
We also have pandoc export an HTML page, which has a few additional javascript elements. This HTML page also experiences the issue, so we can switch to it for debugging (removing the need to deal with pandoc). Currently I get the hangup locally when running the following with Python 3.6.4 and WeasyPrint 0.42 Note that the content at https://greenelab.github.io/scihub-manuscript/ will change, so that URL may no longer trigger the issue in the future. If so, the versioned source for that webpage is preserved here. |
😄
I can't reproduce, even with the preserved version, probably because we don't have the same default font. Could you please tell me what launching |
|
I'm on Ubuntu 17.10: |
I've got the same default font, I don't know why it works for me. I've tried with both 0.42 and master, the PDF is correctly generated. I don't know how I could find what's going on… |
|
I created a docker container, hoping that it would exhibit the error: docker run \
--name=weasyprint-560 \
--interactive --tty \
--entrypoint=bash \
python:3.6Then inside the container's bash shell, I ran: pip install weasyprint==0.42
cd home
git clone --single-branch --branch gh-pages https://github.com/greenelab/scihub-manuscript.git
cd scihub-manuscript
git checkout 0f1a35706985507ab12ad7a8c3c97d99d6e4aaa0
weasyprint index.html weasyprint.pdfThis |
|
I switched to using conda to manage the environment in the Docker, so we can potentially better replicate our error: Then I ran: Unfortnately, Which seems to indicate that cairo is not installed (as per Kozea/CairoSVG#84), although it seems that conda should be installing it. Anyways, I'll update if I make anymore progress. |
|
After i update weasyprint from 0.41 to 0.42 ,I found it could not generate pdf or png sfter it use 90% cpu for 30 minutes. |
|
Hi, I am running into some issues with WeasyPrint getting stuck when creating PDFs from certain HTML files. I have now managed to (kind of) narrow down when this error occurs. My coding skills are insufficient to go into the WeasyPrint code to find out why this is happening; I hope this is helpful anyway. The files are attached. Basically, it's quite strange: On my system, the file "triangulate-error.html" will cause WeasyPrint to go into a kind of infinite loop when printing a page that contains a table; while "triangulate-noerror.html" will create a PDF within a matter of seconds. The only difference between them is in one additional "strong" tag in one of the cells. No error is logged by WeasyPrint. Interestingly, one other way to make the issue disappear is to change the font in the CSS to "Times New Roman". (I have also tried Georgia, Palatino, and my preferred font Iowan Old Style.) My system is macOS Sierra 10.12.6 (16G1212), Python 3.6.4, WeasyPrint version 0.42.1. EDIT: I have looked in-depth at another article that was causing the problem. I now have the suspicion that it is probably something to do with using tags that affect formatting such as "strong" and "em" within brackets, both round and square. |
I can reproduce, thanks a lot for the example. |
|
I updated the test PR (greenelab/scihub-manuscript#39) to use the latest WeasyPrint commit. This changed the build from timing out to failing. See the new error here: Haven't looked at this in detail but wanted to give a heads up. |
I'm really sorry 😞. Your original URL raises the error, I'll fix that and add another non-regression test. |
|
I've checked the tricky part of the new breaking line algorithm that causes these bugs (see #301 and #528). I've added some comments to help us in the future and corrected a couple of problems. I've also added a test to make sure this case won't happen again. I really appreciate the time you take to report the issues and provide examples. If you find other crashes, please report them as well, I'll do my best to fix them as soon as possible! |
No worries! thanks for the fixes. I updated greenelab/scihub-manuscript#39 to use WeasyPrint 79e2b42 and the build succeeded. So I think we're finally good! |
|
I concur, thank you for the (rapid) fixes! I've just run WeasyPrint 0.42.2 against my list of articles that were previously causing problems and they all passed without a hitch. Thank you so much! |
Should upstream fix issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
Fix upstream issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
This build is based on 310dd07. This commit was created by the following Travis CI build and job: https://travis-ci.org/greenelab/manubot-rootstock/builds/338192586 https://travis-ci.org/greenelab/manubot-rootstock/jobs/338192587 [ci skip] The full commit message that triggered this build is copied below: Update environment on 2018-02-06 (#108) Fix upstream issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
This build is based on 310dd07. This commit was created by the following Travis CI build and job: https://travis-ci.org/greenelab/manubot-rootstock/builds/338192586 https://travis-ci.org/greenelab/manubot-rootstock/jobs/338192587 [ci skip] The full commit message that triggered this build is copied below: Update environment on 2018-02-06 (#108) Fix upstream issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
|
Hi, I am running into the problem described above when using weasyprint 0.42.2. This is the html page that is causing the problem for me (https://pewpewthespells.com/blog/sparse_sdks.html). I am also generating the page via pandoc with the following command: When weasyprint is executed and proceeds to get stuck being hung and is killed via local interrupt this is the traceback I get: If you need any other information, please let me know; I would like to get this resolved as quickly as possible. |
Thank you for this report. This issue has been closed with a commit fixing the original bug, so your problem is different even if it leads to the same consequences. Could you please open a separate issue?
So do I! |
Fix upstream issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
Fix upstream issues: Extra brackets around citations in figure captions jgm/pandoc#4272 WeasyPrint 0.42 gets stuck Kozea/WeasyPrint#560 Updated pandoc-xnos with better semantic versioning tomduck/pandoc-fignos#46
We are calling WeasyPrint via pandoc. With 0.42 and a certain input, the command never completes, but does not throw an error, causing builds to timeout.
Downgrading from weasyprint 0.42 to 0.41 solves the issue: greenelab/scihub-manuscript@5cb1245 produced a passing build.
The issue doesn't happen for all inputs (pandoc manuscripts). See for example, this passing build with WeasyPrint 0.42.
The command that fails is:
Any ideas on what the problem could be or how to better diagnose the issue?
The text was updated successfully, but these errors were encountered: