g_thread_proxy: assertion failed: (data)

[kreuzberger]

Building the pdfs from html in the CI system fails sometimes due to the following error:
GLib:ERROR:../glib-2.70.2/glib/gthread.c:814:g_thread_proxy: assertion failed: (data)
It occurs in the windows builds, using current weasyprint from pypi and older version 52.b.
On Windows gtk3-runtime-3.24.31-2022-01-04-ts-win64 is used.
Exit code from weasyprint is returned non-zero exit status 3221225477 if this might be helpful.

The CI system builds documentation and code in parallel, using all available cores.
Any help appreciated.

[liZe]

Hi!

Hmm… We don’t know much about debugging multithreading problems on Windows, unfortunately :). If you know a way to get the whole stacktrace of C function calls, it may be helpful, but otherwise I’m afraid we won’t be really useful to solve this issue.

As the GTK runtime doesn’t include the latest versions of the libraries, the problem may already have been fixed. Instead of the GTK runtime bundle, cou can try to use MSYS2 and install the mingw-w64-x86_64-pango package that will provide all the libraries you need, with more recent versions.

You can get some inspiration from what we do for GitHub’s CI.

[kreuzberger]

due to other bugs i solve it by retrying the build in case of any exceptions. Currently i have timeout and this gtk errors.
Are there any plans to get those library dependencies more "self-contained" into weasyprint? This would be very helpful 👍
This could e.g. also be solved by integrating external package repositories like https://conan.io/center/pango

[kreuzberger]

Workarounded by retrying weasyprint failed builds

[liZe]

Are there any plans to get those library dependencies more "self-contained" into weasyprint? This would be very helpful

It would be very useful. But…

It’s been discussed before (in #1622 for example), but it would be a very heavy maintenance boulder to carry: debugging WeasyPrint’s code on Windows or Mac is already really complex for us, it would be ever more difficult to debug extra problems caused by packaging on different versions of proprietary platforms…

Moreover, creating Windows and Mac executables doesn’t seem to be a priority for our users, so we prefer to spend our free time on other topics for now 😄.

[kreuzberger]

Sorry, self-contained was not meant as complete standalone executable. Found a more related issue #1241. Thanks for your support.

[liZe]

Sorry, self-contained was not meant as complete standalone executable. Found a more related issue #1241.

Yes, that’s another solution! We could generate them with the CI (as executables, actually), but we’re really afraid about the new issues that would probably raise…

[kreuzberger]

Switching to the mingw packages for libpango like you hinted due to your CI builds seems to stable weasyprint usage in a significant way 👍 Maybe this should be added to the official installation documentation.

[liZe]

Switching to the mingw packages for libpango like you hinted due to your CI builds seems to stable weasyprint usage in a significant way Maybe this should be added to the official installation documentation.

Thanks for your feedback.

As the GTK runtime seems to be unmaintained, MSYS2 may be a solution, and adding a small paragraph about that in the documentation is a good idea.

Other possibilities would be to use WSL (already in documentation), to generate wheels including DLLs, or to generate executable files.

[kreuzberger]

Other possibilities would be to use WSL (already in documentation), to generate wheels including DLLs, or to generate executable files.

Currently i try to work on "generate wheels including DLLs". This would help me most on Centos Systems, where all libraries are extremly outdated and there i am forced to use 52.5. Dlls as shared objects.