Cups causes LibreOffice unittests to loop in a sbuild
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cups (Ubuntu) |
Fix Released
|
High
|
Till Kamppeter | ||
sbuild (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
winff (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
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-
apt install cups
wget http://
wget http://
dpkg -i cups-dbgsym_
dpkg -i libcups2-
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/
#4 0x0000000000004002 in ?? ()
#5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMed
#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/
#4 0x0000000000004002 in ?? ()
#5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMed
#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?
Changed in sbuild (Ubuntu): | |
status: | New → Incomplete |
Changed in cups (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in winff (Ubuntu): | |
status: | Fix Committed → Fix Released |
Are there "audit" messages in the syslog file (of the host, of the chroot)?
Can you try to run CUPS in aa-complain mode of AppArmor?
Can you run CUPS in debug mode and supply the error_log file?