Thanks, Paul Gevers, so I a closing the CUPS task now.

** Changed in: cups (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
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:
  Fix Released
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

Reply via email to