registry team mailing list archive

[Bug Watch Updater <241619@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 12 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=15922.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2008-05-13T12:00:37+00:00 mmehnert wrote:

Created an attachment (id=16511)
valgrind output of running dbus-daemon --session

For me, running dbus-daemon fails.

The summary line of the report is the error received.

I recompiled the current debian package 1.2.1-2 with debugging symbols
and ran valgrind.

The output is attached.

I have a feeling that the cause for this is the fact that my root file system is on zfs-fuse (http://zfs-on-fuse.blogspot.com/), since after rebuilding my system this way the problem started to occur. 
Further system details: Kernel 2.6.26-rc2

Shall I take any action to debug this further?

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/0

------------------------------------------------------------------------
On 2008-05-14T08:49:20+00:00 Johnp-redhat wrote:

I have a feeling this has to do with the non-caching userdb code path.
Please look at bug #15588 and compile with caching on to see if this
issue is fixed.  For reference bug #15589 has the noncaching issue.
Basically userinfo structures need to become objects with references.

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/1

------------------------------------------------------------------------
On 2008-05-17T09:31:41+00:00 mmehnert wrote:

I recompiled with --enable-userdb-cache but that did not solve the
problem. :-(

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/2

------------------------------------------------------------------------
On 2008-05-19T06:17:53+00:00 Johnp-redhat wrote:

did you apply the patch also? If not then that flag won't actually do
anythin.  That was part of the bug.

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/3

------------------------------------------------------------------------
On 2008-05-19T07:03:17+00:00 mmehnert wrote:

Yes, I applied that patch :-(

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/4

------------------------------------------------------------------------
On 2008-05-26T07:08:26+00:00 mmehnert wrote:

is there anything I can do to help finding the problem here?

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/5

------------------------------------------------------------------------
On 2008-05-26T09:01:51+00:00 mmehnert wrote:

Having a look at valgrind's
--snip--
Thread 1: status = VgTs_Runnable
==3603==    at 0x4822B8E: realloc (vg_replace_malloc.c:429)
==3603==    by 0x32641: dbus_realloc (dbus-memory.c:601)
==3603==    by 0x32E69: reallocate_for_length (dbus-string.c:364)
==3603==    by 0x32F14: set_length (dbus-string.c:404)
==3603==    by 0x332B2: _dbus_string_lengthen (dbus-string.c:872)
==3603==    by 0x334DC: append (dbus-string.c:1020)
==3603==    by 0x33572: _dbus_string_append (dbus-string.c:1050)
==3603==    by 0x3C8B2: _dbus_directory_get_next_file (dbus-sysdeps-util-unix.c:761)
==3603==    by 0x3E63: update_directory (activation.c:577)
==3603==    by 0x41E0: bus_activation_new (activation.c:771)
==3603==    by 0x6602: process_config_every_time (bus.c:497)
==3603==    by 0x68E2: bus_context_new (bus.c:615)
==3603==    by 0x1B2A1: main (main.c:443)
--snap--

I did a

--snip--

$ gdb /usr/bin/dbus-daemon 
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) break _dbus_directory_open
Breakpoint 1 at 0x3c5ee: file dbus-sysdeps-util-unix.c, line 637.
(gdb) break _dbus_directory_get_next_file
Breakpoint 2 at 0x3c756: file dbus-sysdeps-util-unix.c, line 727.
(gdb) run --session --nofork
Starting program: /usr/bin/dbus-daemon --session --nofork
Breakpoint 1 at 0x3c5db: file dbus-sysdeps-util-unix.c, line 630.
Breakpoint 2 at 0x3c743: file dbus-sysdeps-util-unix.c, line 720.
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x3c5db: Input/output error.
Cannot insert breakpoint 2.
Error accessing memory address 0x3c743: Input/output error.

--snap--

Any idea what that is?

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/6

------------------------------------------------------------------------
On 2008-05-26T13:31:14+00:00 mmehnert wrote:

Created an attachment (id=16746)
changes readdir_r buffer for fuse file system (and maybe others)

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/7

------------------------------------------------------------------------
On 2008-05-26T13:34:06+00:00 mmehnert wrote:

With my latest attachment / patch, dbus works for me with the root file system on fuse. 
It was a bit odd to track down - it turned out that in the calculation of the buffer for readdir_r the maximum length for a filename had a value of 0.

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/8

------------------------------------------------------------------------
On 2008-06-10T03:19:12+00:00 mmehnert wrote:

hmm. any opinion on the patch and/or the problem?
Feedback appreciated.

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/9

------------------------------------------------------------------------
On 2009-02-28T20:07:15+00:00 DaveAbrahams wrote:

I can confirm this problem and that the patch fixes it.

FWIW, *my* only FUSE filesystem is mounted at /usr

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/16

------------------------------------------------------------------------
On 2009-03-01T08:42:50+00:00 Hp-pobox wrote:

This code requires some care:
http://womble.decadentplace.org.uk/readdir_r-advisory.html

There is no indication in the standard that fpathconf should ever be returning 0:
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html

Surely this is a bug in fuse.

Not sure falling back to PATH_MAX is safe. In fact I think it isn't.
readdir_r will smash the stack if the filename is longer than the
buffer...

Reply at: https://bugs.launchpad.net/dbus/+bug/241619/comments/18


** Changed in: dbus
   Importance: Unknown => Critical

-- 
dbus fails to start on FUSE filesystems
https://bugs.launchpad.net/bugs/241619
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for D-Bus.