[Bug 13130] Re: Debconf uninitialized variable

[Chip Rosenthal]

I just added myself as "having this issue" but the more I look at it the
more I believe this is a filesystem issue. Both my /var/lib/dpkg and
/var/cache/debconf directories look unhealthy (files appear to be
truncated, corrupted, etc.)

This is on a laptop system running on a SSD ex4 with no journal (i.e.
very susceptible to problems on ungraceful shutdown).

You could argue this is not an application issue, but the package
manager is such an essential part and the filesystem structure is so
complicated, I wonder if some sort of integrity tests/better diagnostics
might be called for.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to debconf in Ubuntu.
https://bugs.launchpad.net/bugs/13130

Title:
  Debconf uninitialized variable

Status in “debconf” package in Ubuntu:
  Triaged

Bug description:
  I get the following when installing/removing packages:

  Use of uninitialized value in substitution (s///) at
  /usr/share/perl5/Debconf/Format/822.pm line 57, <$__ANONIO__> line 1.
  Use of uninitialized value in substitution (s///) at
  /usr/share/perl5/Debconf/Format/822.pm line 57, <$__ANONIO__> line 4.
  Use of uninitialized value in substitution (s///) at
  /usr/share/perl5/Debconf/Format/822.pm line 57, <$__ANONIO__> line 5.
  Use of uninitialized value in substitution (s///) at
  /usr/share/perl5/Debconf/Format/822.pm line 57, <$__ANONIO__> line 6.
  Use of uninitialized value in hash element at
  /usr/share/perl5/Debconf/DbDriver/File.pm line 51, <$__ANONIO__> chunk 15.

  I'm no expert but it seems to be related to the following bit of code
  in 822.pm:

  my $invars=0;
  my $line;
  while ($line = <$fh>) {
          chomp $line;
          last if $line eq ''; # blank line is our record delimiter
          if ($invars) {
                  if ($line =~ /^\s/) {
                          $line =~ s/^\s+//;
                          my ($var, $value)=split(/\s*=\s?/, $line, 2);
                          $value=~s/\\n/\n/g;
                          $ret{variables}->{$var}=$value;
                          next;
                  }
                  else {
                          $invars=0;
                  }
          }
          ... blah, blah, blah ...
  }

  IIRC $invars=0 will cause it to evaluate to boolean false, in which case it will
  get set to 0 again which makes no sense. Because $invars is set to 0 this means
  that the first code block of the if statement gets skipped and $value doesn't
  get set which leads to an error when we get to:

  elsif (length $key) {
          $value=~s/\\n/\n/g;
          $ret{fields}->{$key}=$value;
  }

  So it looks to my untrained eye as if $invars should initially be set
  to 1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/13130/+subscriptions