assertion failed in file dbus-errors.c line 278.

[Paul Sladen]

Seen once every five-seconds during 9.04->9.10 alpha 5 upgrade:

process 384: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL || !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 278.
This is normally a bug in some application using the D-Bus library.

chipcard 384 0.0 0.0 6516 1664 pts/5 S+ 06:25 0:00 /usr/sbin/chipcardd4 --pidfile /var/run/chipcard/chipcardd4.pid --exit-on-error

and then later in the log:

3:2009/09/15 06-54-28: (null)(384):chipcardd.c: 1236: Closing GWEN

after the upgrade there were two processes running:

chipcard 383 0.0 0.0 6384 724 ? S 06:25 0:00 /usr/sbin/chipcardd4 --pidfile /var/run/chipcard/chipcardd4.pid --exit-on-error
chipcard 7765 0.0 0.0 6516 1720 ? S 06:54 0:00 /usr/sbin/chipcardd4 --pidfile /var/run/chipcard/chipcardd4.pid --exit-on-error

The first of these has a PID one lower than the process (394) generating the repeated D-Bus errors.

[Micha Lenk (micha)]

Please make sure that HAL is started *before* the chipcard daemon. Unless you touched the boot symlinks in /etc/rc*.d/ this should have been handled on upgrade automatically (see also file /usr/share/doc/libchipcard-tools/NEWS.Debian).

[Paul Sladen (sladen)]

Micha: nothing has been fiddled here; if chipcardd is making erroneously formatted DBus calls then it should be *fixed* to not do so.

If chipcardd is being pushed as a daemon that is deemed necessary to run 24x7 on everyone's machines then it should do that reliably.

[Micha Lenk (micha)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

Paul Sladen schrieb:
> Micha: nothing has been fiddled here;

Sorry, I did not intend to offend you.

> if chipcardd is making
> erroneously formatted DBus calls then it should be *fixed* to not do so.
>
> If chipcardd is being pushed as a daemon that is deemed necessary to run
> 24x7 on everyone's machines then it should do that reliably.

I totally agree.

The issue is that the chipcard daemon needs to be started when HAL is
running. If it isn't you will get DBus errors.

Can you please confirm that you don't get the DBus errors if you start
the chipcard daemon when HAL is running on your system?

Regards
  Micha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqyu8IACgkQWN0/4pnhQbQHIgCfY9jr+JxV6PVpBxOdMSuKzyuw
UsgAn1/juwgtosvo3iZV2p91aXxhbnxU
=1NQ9
-----END PGP SIGNATURE-----

[Paul Sladen (sladen)]

If I'm a dumb user, I have no idea what "HAL" is, or what "libchipcard" is, or how to "start" or "stop" them.

If libchipcard is getting started in the wrong order, then that is something that needs fixing in the packaging.

If HAL is a dependency of libchipcard and is not found running (eg. HAL crashed, or was restarted during an upgrade asi in this case) then libchipcard needs to deal with that situation and cope with it, not generate errors. ...libchipcard should *check* if HAL running, before attempting to call it. If something fails and nothing has changed, trying to perform the same operation 10 seconds later is _also_ likely to fail.

At no point should libchipcard ever be generating errors though its own inaction or lack of error/sanity checking before or after performing RPC.

Lack of such error+sanity checking is probably also an indication of potential security issues.

(Back to being a dump user---if I hit the power switch, the machine should "just work"...)

[Micha Lenk (micha)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

Paul Sladen wrote:
> If I'm a dumb user, I have no idea what "HAL" is, or what "libchipcard"
> is, or how to "start" or "stop" them.
>
> If libchipcard is getting started in the wrong order, then that is
> something that needs fixing in the packaging.

I was trying to figure what happens on your system in order to decide
whether it is the packaging or not. But you gave no answer: "Can you
please confirm that you don't get the DBus errors if you start
the chipcard daemon when HAL is running on your system?"

Sorry for not giving you more precise instructions earlier, but from
what I've read from you it didn't really sound like a dumb user...

Is hal installed at all on your system? What output do you get by
running "dpkg -l hal" on your system? If it is not installed, you have
deliberately elided the package dependency of libchipcard-tools
recommending hal. Then please install hal manually first.

Please run the following commands and report back the resulting output
after every command:

/etc/init.d/libchipcard-tools stop
/etc/init.d/hal stop
/etc/init.d/hal start
/etc/init.d/libchipcard-tools start

After this procedure you shouldn't get any errors (if the issue really
is what I believe).

> If HAL is a dependency of libchipcard and is not found running (eg. HAL
> crashed, or was restarted during an upgrade asi in this case) then
> libchipcard needs to deal with that situation and cope with it, not
> generate errors. ...libchipcard should *check* if HAL running, before
> attempting to call it. If something fails and nothing has changed,
> trying to perform the same operation 10 seconds later is _also_ likely
> to fail.
>
> At no point should libchipcard ever be generating errors though its own
> inaction or lack of error/sanity checking before or after performing
> RPC.

I totally agree -- any patch is appreciated. Feel free to contribute and
improve free software.

Regards
  Micha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5Y1YACgkQWN0/4pnhQbRtvwCglLgdP05BeLhanx5hXVgfguze
OmYAoLEA7HXCepNSsCajkikbEn2VBbaA
=GiL4
-----END PGP SIGNATURE-----

[Darxus (darxus)]

I'm also getting this error:

process 5539: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL || !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 278.
This is normally a bug in some application using the D-Bus library.

Output of "sudo apport-cli 5539" attached.

[Darxus (darxus)]

dpkg -l hal:
ii hal 0.5.13-1ubuntu7

I'm getting the error during "do-release-upgrade -d" today, from jaunty (updated before upgrading) to karmic beta.

[Darxus (darxus)]

$ ps auxww | egrep -i 'hal|chip'
chipcard 654 0.7 0.0 6512 1684 ? S 23:08 0:00 /usr/sbin/chipcardd4 --pidfile /var/run/chipcard/chipcardd4.pid --exit-on-error
darxus 666 0.0 0.0 3120 828 pts/9 R+ 23:09 0:00 egrep -i hal|chip
107 1343 0.0 0.1 6364 4052 ? Ss 23:01 0:00 hald --daemon=yes
root 1344 0.0 0.0 3564 1180 ? S 23:01 0:00 hald-runner
root 1384 0.0 0.0 3648 1128 ? S 23:01 0:00 /usr/lib/hal/hald-addon-cpufreq
107 1385 0.0 0.0 3464 1124 ? S 23:01 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
darxus 3598 0.0 0.0 33456 2036 ? Sl Oct01 0:00 /usr/lib/gvfs/gvfs-hal-volume-monitor
chipcard 5538 0.0 0.0 6380 752 ? S 22:38 0:00 /usr/sbin/chipcardd4 --pidfile /var/run/chipcard/chipcardd4.pid --exit-on-error
root 9012 0.0 0.0 3640 1228 ? S 23:03 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)

Looks like hal was started after the chipcard.

[Micha Lenk (micha)]

Hi Martin,

the HAL scanner code doesn't correctly initialize the HAL context it
uses. This causes the libchipcard HAL scanner to not fail if the HAL
daemon isn't running. This in turn causes ugly error messages like those
reported in the following two bug reports:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532893
https://bugs.launchpad.net/debian/+source/libchipcard/+bug/429853

The attached patch fixes this issue and enables libchipcard's
HAL scanner to correctly detect whether HAL is running or not.

Regards
  Micha

[David Tombs (dgtombs)]

This will be fixed with bug 589920.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libchipcard - 4.2.9-2

---------------
libchipcard (4.2.9-2) unstable; urgency=low

  * Update udev rules now using ATTR{} instead of SYSFS{} attributes
    (closes: #563086).
  * Package is compliant to Debian Policy 3.8.4 (no changes needed).

libchipcard (4.2.9-1) unstable; urgency=low

  * New upstream release
    + fixes faulty use of D-BUS protocol (closes: #532893, LP: #429853)
    + doesn't show confusing "Closing GWEN" message anymore (LP: #429887).
  * libchipcard-dev: Fix weak library dependencies on libchipcardc2 and
    libchipcard-ctapi0 (thanks to lintian).
  * Fix typos in package descriptions (closes: 557498, 557499, 557500, 557501).
    Thanks to Pascal De Vuyst for pointing them out.
  * Improve NEWS entry for libchipcard-tools, clarifying that a
    disabled init script will need a manual check for correct boot order.

libchipcard (4.2.8-2) unstable; urgency=low

  * Clean up directory /var/run/chipcard/ on purge of libchipcard-tools.
  * Bump standards version. Package is compliant to standards version 3.8.3 now
    (no changes needed).
  * Improve bug script to include information about used resource manager and
    pcscd package/daemon status.
  * Add comments about usage with pcscd to README.Debian for packages
    libchipcard-tools and libchipcardc2 (closes: #362844).
  * Don't ship .la-files for plugin shared libraries any more.
  * Update maintainer's mail address and drop DM upload privileges.
  * Change init.d LSB header dependency on hal to a soft dependency
    (closes: #548581). Thanks to Petter Reinholdtsen for providing the patch.
  * Let init script provide libchipcard-tools in init.d LSB headers.
  * Add new symbols (stuff like *_GetLinkCount) to symbols file.
 -- Felix Geyer <email address hidden> Sat, 06 Mar 2010 12:41:58 +0100