Hi, I am not sure this is related or not but let me share: Iceweasel/Firefox-esr: Temporal freeze when print/print preview https://lists.debian.org/debian-devel/2016/09/msg00255.html
In this issue, browsers' printing function always cause temporal freeze where Cups is never installed. Once Cups (and the related packages) is installed, no hangs any more even after Cups is uninstalled. The following is the list of installed packages with the name of cups: % aptitude search cups | grep ^i i A libcups2 - Common UNIX Printing System(tm) - Core lib i A libcupsfilters1 - OpenPrinting CUPS Filters - Shared library i A libcupsimage2 - Common UNIX Printing System(tm) - Raster i Taro -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1616548 Title: Cups causes LibreOffice unittests to loop in a sbuild Status in cups package in Ubuntu: Confirmed Status in sbuild package in Ubuntu: Incomplete Status in winff package in Ubuntu: Fix Committed Bug description: When building LibreOffice 1:5.2.0-0ubuntu1 on a xenial host with a yakkety sbuild, e.g. by: sbuild -A -d yakkety-amd64 (...).dsc this loops/busy hangs with unittests. This was working ok up to 5.2.0~rc4 (=final), it is a regression by a LibreOffice dependency, most likely CUPS, which was updated. I tried to inject debug symbols by running with a: --chroot-setup- command and then run something along the lines of: apt install cups wget http://launchpadlibrarian.net/278966811/cups-dbgsym_2.2~rc1-4_amd64.ddeb wget http://launchpadlibrarian.net/278966816/libcups2-dbgsym_2.2~rc1-4_amd64.ddeb dpkg -i cups-dbgsym_2.2~rc1-4_amd64.ddeb dpkg -i libcups2-dbgsym_2.2~rc1-4_amd64.ddeb before starting the build proper, but I got only marginally better debug info. The hanging LibreOffice test processes usually have 2-4 child processes. The parent and one of the childs are busy, while the rest idle. Here is a stacktrace of the busy child: Program received signal SIGPIPE, Broken pipe. 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 43 in fgetspent.c (gdb) bt #0 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 #1 0x000000000000001e in ?? () #2 0x000055c4976981e0 in ?? () #3 0x00002b0a8aff8d20 in ipp_options () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #4 0x0000000000004002 in ?? () #5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMediaDefault+415>, section=29, min_order=0, choices=0x2b0a8adad6f3 <cupsFileGetConf+467>) at emit.c:145 #6 0x0000000000000000 in ?? () Here is a stacktrace of the busy parent: Thread 3 "CUPSManager cup" received signal SIGPIPE, Broken pipe. 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 43 in fgetspent.c (gdb) bt #0 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 #1 0x000000000000001e in ?? () #2 0x000055c4976981e0 in ?? () #3 0x00002b0a8aff8d20 in ipp_options () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #4 0x0000000000004002 in ?? () #5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMediaDefault+415>, section=29, min_order=0, choices=0x2b0a8adad6f3 <cupsFileGetConf+467>) at emit.c:145 #6 0x0000000000000000 in ?? () When pressing "c" in gdb to continue, both processes stop very quickly again with the SIGPIPE. Venturing a guess: Is the signal handling of CUPS b0rked? As fgetspent reads the shadow file[1], maybe there are missing permissions or other sandbox issues that CUPS doesnt handle error cases for properly? [1] http://linux.die.net/man/3/fgetspent To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1616548/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
