libsoftbeep strips BELs inappropriately

[Sam Hathaway]

Binary package hint: gconf2

This is a problem in Edgy, as upgraded from Dapper. I did not see it in Dapper.

A long time ago, during the installation of some package that uses gconf, the configuration phase of the installation failed with the following error:

Failed to write "/var/lib/gconf/defaults/%gconf-tree.xml": Error writing file "/var/lib/gconf/defaults/%gconf-tree.xml.new": File exists

I forget which package originally triggered the error, I just started noticing it during upgrades at some point.

Since then, every package that uses gconf (and tries to install a schema) fails to configure with that same error. Investigating, I found no evidence of a %gconf-tree.xml.new file. I tried all sorts of things, including starting from an empty %gconf-tree.xml file and manually installing all the schemas. Nothing worked, so I put the /var/lib/gconf directory back the way I found it.

I have another similarly-configured Edgy box that was also upgraded from Dapper that does not exhibit this problem. I installed all the same gconf-using packages on that box, and then copied the entire /var/lib/gconf directory from the working box to the broken box. No dice.

In desperation, I reinstalled the system -- this time, a clean Edgy install. I didn't reformat the hard drive, but I moved everything out of the way and then directed the installer to use the existing filesystem. After this, packages that wanted to install gconf schemas worked fine -- UNTIL TODAY.

I upgraded evince from 0.6.1-0ubuntu1.1 to 0.6.1-0ubuntu1.2 today, and during the configuration phase, I got the same error! Re-configuriung (with dpkg --configure --pending) doesn't help, and again there's no %gconf-tree.xml.new file in /var/lib/gconf.

The line in evince.postinst that triggers the bug is:

gconf-schemas --register evince-thumbnailer-djvu.schemas evince-thumbnai
ler-dvi.schemas evince-thumbnailer.schemas evince.schemas

This is a fairly disruptive bug for some packages, since they can't install their gconf schemas at all, and any configuration that happens after gconf-schemas is called doesn't happen.

[Sam Hathaway (sam.hathaway)]

Binary package hint: gconf2

This is a problem in Edgy, as upgraded from Dapper. I did not see it in Dapper.

A long time ago, during the installation of some package that uses gconf, the configuration phase of the installation failed with the following error:

Failed to write "/var/lib/gconf/defaults/%gconf-tree.xml": Error writing file "/var/lib/gconf/defaults/%gconf-tree.xml.new": File exists

I forget which package originally triggered the error, I just started noticing it during upgrades at some point.

Since then, every package that uses gconf (and tries to install a schema) fails to configure with that same error. Investigating, I found no evidence of a %gconf-tree.xml.new file. I tried all sorts of things, including starting from an empty %gconf-tree.xml file and manually installing all the schemas. Nothing worked, so I put the /var/lib/gconf directory back the way I found it.

I have another similarly-configured Edgy box that was also upgraded from Dapper that does not exhibit this problem. I installed all the same gconf-using packages on that box, and then copied the entire /var/lib/gconf directory from the working box to the broken box. No dice.

In desperation, I reinstalled the system -- this time, a clean Edgy install. I didn't reformat the hard drive, but I moved everything out of the way and then directed the installer to use the existing filesystem. After this, packages that wanted to install gconf schemas worked fine -- UNTIL TODAY.

I upgraded evince from 0.6.1-0ubuntu1.1 to 0.6.1-0ubuntu1.2 today, and during the configuration phase, I got the same error! Re-configuriung (with dpkg --configure --pending) doesn't help, and again there's no %gconf-tree.xml.new file in /var/lib/gconf.

The line in evince.postinst that triggers the bug is:

gconf-schemas --register evince-thumbnailer-djvu.schemas evince-thumbnai
ler-dvi.schemas evince-thumbnailer.schemas evince.schemas

This is a fairly disruptive bug for some packages, since they can't install their gconf schemas at all, and any configuration that happens after gconf-schemas is called doesn't happen.

[Sam Hathaway (sam.hathaway)]

I remembered what initially caused the problem on my original installation. The first time I saw the error was after downgrading totem (and totem-gstreamer) from 1.4.3-0ubuntu1 to 1.4.1-0ubuntu4. I did this because the totem browser plugin wasn't available for 1.4.3-0ubuntu1.

Re-upgrading totem and totem-gstreamer didn't fix it.

Likewise, reversing the evince upgrade that caused it on this installation doesn't fix it either.

[Sam Hathaway (sam.hathaway)]

More experimentation:

I again copied my /var/lib/gconf directory from my other (non-broken) Edgy box, and am doing some experiments with that.

One test is to unregister and then register a single schema. I did this with evince-thumbnailer-djvu.schemas:

# With virgin gconf dir from spider, unregister single schema:
root@bunny:~# gconf-schemas --unregister evince-thumbnailer-djvu.schemas

# So far so good, now register that schema again:
root@bunny:~# gconf-schemas --register evince-thumbnailer-djvu.schemas
Failed to write "/var/lib/gconf/defaults/%gconf-tree.xml": Error writing file "/var/lib/gconf/defaults/%gconf-tree.xml.new": File exists

Error syncing config data: Failed to write some configuration data to disk

At this point, %gconf-tree.xml.new DOES exist, and consists of the first 30,839 lines of %gconf-tree.xml.

The last identical line is:
                                         <dir <email address hidden>">
In %gconf-tree.xml, this is immediately followed by:
                                        </dir>
but in %gconf-tree.xml.new, we get this:
                                                <entry name="command" mtime="1165517165" type="schema" stype="string" owner="evince">
                                                        <local_schema locale="C" short_desc="">
                                                                <default type="string">
                                                                        <stringvalue>evince-thumbnailer -s %s %u %o</stringvalue>
                                                                </default>
                                                                <longdesc>
And that's the end of the file. There isn't even a closing newline.

Digging deeper, I found out the exact command that gconf-schemas was running, and executed it manually:

# With virgin gconf dir from spider, uninstall single schema:
root@bunny:~# HOME=/tmp/gconf--3PMME GCONF_CONFIG_SOURCE=xml:readwrite:/var/lib/gconf/defaults gconftool-2 --makefile-uninstall-rule /usr/share/gconf/schemas/evince-thumbnailer-djvu.schemas
Resolved address "xml:readwrite:/var/lib/gconf/defaults" to a writable configuration source at position 0
Attached schema `/<email address hidden>/enable' to key `/<email address hidden>/enable'
Uninstalled schema `/<email address hidden>/enable' from locale `C'
Attached schema `/<email address hidden>/command' to key `/<email address hidden>/command'
Uninstalled schema `/<email address hidden>/command' from locale `C'

# So far so good, now install that schema again:
root@bunny:~# HOME=/tmp/gconf--3PMME GCONF_CONFIG_SOURCE=xml:readwrite:/var/lib/gconf/defaults gconftool-2 --makefile-install-rule /usr/share/gconf/schemas/evince-thumbnailer-djvu.schemas
Resolved address "xml:readwrite:/var/lib/gconf/defaults" to a writable configuration source at position 0
Attached schema `/<email address hidden>/enable' to key `/<email address hidden>/enable'
Installed schema `/schemas/desktop/gnome/thumbnailers/i...

[Sam Hathaway (sam.hathaway)]

The error message is generated by the gconf source file backends/markup-tree.c in the save_tree_with_locale function on line 4480.

That code assumes that if there was an error, (i.e. write_failed is true) it was caused by something that sets errno. However, there are plenty of ways for an error to occur that don't result in errno getting set.

The write_entry function (called by save_tree_with_locale) calls a lot of fprintf and fputs, and if any of those fail, it returns a negative value (which causes save_tree_with_locale to set write_failed to true. Unless I'm mistaken, fprintf and fputs don't set errno. (Or at least the manpage doesn't mention setting errno.)

So the "Inappropriate ioctl for device" error is totally bogus.

Incidentally, the "<longdesc>" element is written on line 4025 (in write_local_schema_info, which is called by write_entry). Maybe that fprintf is returning a negative value? Or, maybe the next thing (printing the long_desc itself, with fputs) is failing?

I'm planning to add some debugging statements around there when I have some time. But right now, time for lunch.

[Sam Hathaway (sam.hathaway)]

Ok... the line that causes gconftool to bail out is a call to fputs on line 4030 of markup-tree.c (in the function write_local_schema_info). Here's the surrounding chunk of code:

  if (write_descs && local_schema->long_desc)
    {
      if (fprintf (f, "%s<longdesc>", whitespace2) < 0)
        goto out;

      s = g_markup_escape_text (local_schema->long_desc, -1);

      if (fputs (s, f) < 0)
        {
          g_free (s);
          goto out;
        }

      g_free (s);

      if (fputs ("</longdesc>\n", f) < 0)
        goto out;
    }

What's happening is that local_schema->long_desc is an empty string, and fputs apparently returns EOF if you pass it an empty string.

So now the question becomes what changed that caused this code to get run even if long_desc is an empty string?

[Sam Hathaway (sam.hathaway)]

Ok, here's my workaround. This results in output identical to the output of the non-patched gconf on you working system. It probably just masks the real problem, though.

So what changed to cause local_schema->long_desc to be defined but point to an empty string? Who knows? The schema files are the same on the working and non-working system. All the packages that are installed on both systems are at the same version (except ssh, which I patched to include sftp logging).

[Sam Hathaway (sam.hathaway)]

I figured out what was different on the to machines, and boy is it lame. On the non-working machine, I had added /usr/lib/softbeep/libsoftbeep.so to /etc/ld.so.preload. Apparently, this package is not as clever as it should be at differentiating between beeps and non-beeps.

[Sam Hathaway (sam.hathaway)]

affects /distros/ubuntu/softbeep

[Sam Hathaway (sam.hathaway)]

 affects /distros/ubuntu/softbeep

[Sam Hathaway (sam.hathaway)]

I don't know how to reassign a bug to a new package, so someone else will have to do it for me.

[Sebastien Bacher (seb128)]

from the bug package you can click on the task, it'll expand the settings for it and you can change the source package name. What does softbeep has to do with gconf though?

[Sam Hathaway (sam.hathaway)]

Among other things, softbeep intercepts the write() system call in order to look for BEL characters that are being written to a TTY. It strips them out and instead calls a program.

It has to intercept *every* write call, and then decide which ones are applicable. Apparently, it is not always accurate about what is a TTY and what isn't.

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

I found another way to produce the problem, instead of running:
softbeep bash
I set this environment variable:
LD_PRELOAD="$LD_PRELOAD /usr/lib/softbeep/libsoftbeep.so"

It seems that this is what actually causes the problem.

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

forwarded 294693 <email address hidden>

[Lionel Le Folgoc (mrpouit)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

tags 294693 help
severity 294693 important

--
 أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net)
 GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello,

  A while ago I run 'dia' from terminal window, in which LD_PRELOAD was
  set to /usr/lib/softbeep/libsoftbeep.so. When I saved the resulting
  file in compressed format (gzipped XML file), it got corrupted indeed
  ! That does not happen when I do not set LD_PRELOAD to
  /usr/lib/softbeep/libsoftbeep.so.

  Same thing for mutt, I can't open any email in a terminal in which
  LD_PRELOAD is set to /usr/lib/softbeep/libsoftbeep.so. Although I do
  not really understand how this relates to zlib.

--
 أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net)
 GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello,

  When running a software that uses zlib from a shell run from softbeep.
  The resulting file is corrupted. I have attached the full Debian bug
  report log for this bug (Bug #294693).

  Please preserve the CC to <email address hidden> when
  replying, so that the Debian bug tracking system will file their reply
  with the original report.

Debian Bug report logs - #294693
softbeep: softbeep causes darcs (zlib1g?) corruption

 From: Joe Edmonds <email address hidden>
 To: Debian Bug Tracking System <email address hidden>
 Subject: softbeep: softbeep causes darcs (zlib1g?) corruption
 Date: Thu, 10 Feb 2005 21:43:02 -0800

 Package: softbeep
 Version: 0.3-10
 Severity: normal

 If I run "darcs record" from a shell run from softbeep, the compressed
 patch it creates is corrupted. Maybe this is due to a bad interaction
 between softbeep and zlib1g (and darcs?)?

 To reproduce, you'll need to install the darcs package and then
 execute command sequence [2] below. Note that [1] works OK and [3],
 which tells darcs not to compress the patch also works OK.

 [1]
 # make sure you're not running inside softbeep
 mkdir darcstest
 cd darcstest
 date > file1.txt
 darcs init
 darcs add file1.txt
 echo <email address hidden> > _darcs/prefs/author
 darcs record -a -m test --skip-long-comment
 zless _darcs/patches/*.gz

 [2]
 softbeep bash
 mkdir darcstest
 cd darcstest
 date > file1.txt
 darcs init
 darcs add file1.txt
 echo <email address hidden> > _darcs/prefs/author
 darcs record -a -m test --skip-long-comment
 zless _darcs/patches/*.gz

 [3]
 softbeep bash
 mkdir darcstest
 cd darcstest
 date > file1.txt
 darcs init
 darcs add file1.txt
 echo <email address hidden> > _darcs/prefs/author
 darcs record -a -m test --skip-long-comment --dont-compress
 less _darcs/patches/*.gz # darcs names uncompressed patches .gz too

 -- System Information:
 Debian Release: 3.1
   APT prefers unstable
   APT policy: (990, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.10-1-686
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

 Versions of packages softbeep depends on:
 ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an

 -- no debconf information

 From: Ahmed El-Mahmoudy <email address hidden>
 To: <email address hidden>
 Subject: Re: softbeep: softbeep causes darcs (zlib1g?) corruption
 Date: Sat, 27 Jan 2007 14:05:13 +0200

 I found another way to produce the problem, instead of running:
 softbeep bash
 I set this environment variable:
 LD_PRELOAD="$LD_PRELOAD /usr/lib/softbeep/libsoftbeep.so"

 It seems that this is what actually causes the problem.

 From: أحمد المحمودي <email address hidden>
 To: <email address hidden>
 Subject: It is related to zlib1g indeed !
 Date: Sun, 17 Feb 2008 08:45:43 +0200

 Hello,

   A while ago I run 'dia' from terminal window, in which LD_PRELOAD was
   set to /usr/lib/softbeep/libsoftbeep.so. When I saved the resulting
   file in compressed format (gzipped XML file), it got corrupted indeed
   ! That does not happen when I do not set LD_PRELOAD to
   /usr/lib/softbeep/libsoftbeep.so.

   Same thing for mutt, I can't open any email in a terminal in w...

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

forwarded 294693 [e-mail]

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello,

  Is that the same bug as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294693 ?

[Sam Hathaway (sam.hathaway)]

Yes, that looks like the same bug.

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

On Tue, Mar 11, 2008 at 02:40:41PM -0000, Sam Hathaway wrote:
> Yes, that looks like the same bug.
---end quoted text---

I've been trying to debug the problem, but I was not able to find what
function causes it.

--
 أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
  SySDSoft, Inc.
 GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net)
 GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Same as bug #294693 on Debian. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294693)

[Sam Hathaway (sam.hathaway)]

An alternative for those who dislike their console beep is the "fancy beeper" kernel module available at <http://carcosa.net/jason/software/beep/>.

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello,

  Actually I found that the pcspkr module that comes with Hardy does the
  job too. It makes beeps on my laptop even though I don't have a PC
  speaker on that laptop.

On Wed, Apr 02, 2008 at 09:38:14PM -0000, Sam Hathaway wrote:
> An alternative for those who dislike their console beep is the "fancy
> beeper" kernel module available at
> <http://carcosa.net/jason/software/beep/>.
---end quoted text---

--
 أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
  SySDSoft, Inc.
 GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net)
 GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27

[أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy)]

Hello,

  I was just looking at softbeep's README today, and I found this info about an 'SB_REMOVE_BEL' environment variable:

When SB_REMOVE_BEL is set to "yes" every catched BEL character written to a TTY
is dropped, otherwise it is passed to the next layer.