[Debconf-devel] Bug#460916: got it with bash-completion

[Niko Tyni]

On Sat, Mar 01, 2008 at 04:03:24PM +0100, Yann Dirson wrote:
 
> >From this it looks like the parent frontend is waiting for data from
> the child frontend, while the latter tries to write to its parent.At
> least this seems to explain why the load has dropped :)

I can confirm this. It's 100% reproducible here by doing this:

# echo test > /etc/bash_completion
# apt-get install bash-completion
[select the sdiff option]

The source file is ~10k lines, 200k bytes:
  9322  30098 214778 /usr/share/bash/bash_completion

The problem goes away if I chop the source in half and then do a 
'dpkg --configure -a', so it's clearly the size that matters.
I can't reproduce the problem with libsensors4 or libsensors3 (#435929),
but I assume it's the same issue as their files are quite big too.

With 'set -x' in ucf, we see it's db_go blocking (right after the
db_subst and db_input in show_diff()):

  + db_input critical ucf/show_diff
  + _db_cmd 'INPUT critical' ucf/show_diff
  + IFS=' '
  + printf '%s\n' 'INPUT critical ucf/show_diff'
  + IFS='
  '
  + read -r _db_internal_line
  + RET='question will be asked'
  + case ${_db_internal_line%%[   ]*} in
  + return 0
  + db_go
  + _db_cmd 'GO '
  + IFS=' '
  + printf '%s\n' 'GO '
  + IFS='
  '
  + read -r _db_internal_line
  
and strace+lsof show a child frontend blocking on a write to its parent
frontend on FD 2, while the parent is reading from the same child on
FD 10.

I assume the deadlock occurs because the pipe buffers fill up. Suggest
cloning to debconf and cutting overly long diff output in ucf. It's not
like anyone is going to make an informed decision by reading a 100k diff
presented by debconf...

Cheers,
-- 
Niko Tyni   ntyni at debian.org