that's the upstream bug https://github.com/apple/cups/issues/4870 "libcups attempted to connect to daemon endlessly if there's no daemon running"
-- 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
