Bug #530605 “gvfs-mount doesn't always work. gvfsd-smb starts us...” : Bugs : libgnome-keyring package : Ubuntu

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-02:

#1

Dependencies.txt Edit (4.0 KiB, text/plain; charset="utf-8")

description:

updated

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-02:

#2

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in gvfs (Ubuntu):
importance:	Undecided → Low

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-02:

#3

Reported upstream: https://bugzilla.gnome.org/show_bug.cgi?id=611584

Sebastien Bacher (seb128) on 2010-03-02

Changed in gvfs (Ubuntu):
status:	New → Triaged

Revision history for this message

axoin (axoin) wrote on 2010-03-02:

#4

i can confirm that on 10.04 alpha 3

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-11:

#5

Hey axion, can you also add your +1 to the bug on Bugzilla? The more the merrier (and the more attention it will get).

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-13:

#88

Description of problem:
Not possible to see samba share in Nautilus.
Write smb: into location.
Then "Windows Network" appears in header. Wait over 10 seconds and then
error window comes.

Version-Release number of selected component (if applicable):
samba-3.5.1-58.fc13.x86_64
system-config-samba-1.2.86-1.fc13.noarch
samba-winbind-clients-3.5.1-58.fc13.x86_64
samba-common-3.5.1-58.fc13.x86_64

selinux-policy-3.7.11-1.fc13.noarch
libselinux-2.0.90-5.fc13.x86_64
libselinux-utils-2.0.90-5.fc13.x86_64
selinux-policy-targeted-3.7.11-1.fc13.noarch
libselinux-python-2.0.90-5.fc13.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Open Nautilus and Ctrl+l
2. Write smb: into Lotstion
3. Wait over 10 seconds
and error window
The folder contents could not be displayed.

Actual results:
Error window
The folder contents could not be displayed.
Sorry, could not display all the contents of "Windows Network": DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Expected results:
To see enabeld samba shares
There is local sama share

Additional info:
Just rebooted to reapply selinux policy
There is no message in /var/log/messages
It is possible to see local samba share form another computer ( F12 )

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-13:

#89

Created attachment 399847
messages after settin selinux in permissive mode

When setting selinux in permissive mode then it possible to see local samba share
but not open it.

Revision history for this message

In Red Hat Bugzilla #573202, Simo (simo-redhat-bugs) wrote on 2010-03-13:

#90

Can you check your firewall settings are not blocking samba client packetes ?

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-13:

#91

>Can you check your firewall settings are not blocking samba client packetes ?

samba and samba client are marked as trusted.
Fierwall disabled
The folder contents could not be displayed.
Sorry, could not display all the contents of "Windows Network": DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

no message i /var/log/messages

--------------------------------
If seleinux in permissive
Mar 13 18:15:25 flokic dbus: avc: received setenforce notice (enforcing=0)
Mar 13 18:15:25 flokic dbus: avc: received setenforce notice (enforcing=0)
Mar 13 18:15:25 flokic dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" sauid=81 hostname=? addr=? terminal=?

and error window
Unable to mount location
Sorry, could not display all the contents of "Windows Network": DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Revision history for this message

In Red Hat Bugzilla #573202, Simo (simo-redhat-bugs) wrote on 2010-03-13:

#92

Sorry but this looks like a nautilus or gnome-vfs problem to me.

Reassigning.

Revision history for this message

MichaelB (mrbou) wrote on 2010-03-15:

#6

I have the same problem (Lucid Alpha 3). Work with share folder "without authentication" BUT fail with authentication (gvfsd-smb 100% cpu). I have only shared smb folder (NAS) with authentication.. I really hope this bug will be fixed for Lucid release.

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-15:

#93

I see in top that gvfsd-smb-brows is with cpu over 90%

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-16:

#7

is that a duplicate of bug #532024?

Sebastien Bacher (seb128) on 2010-03-16

Changed in gvfs (Ubuntu Lucid):
assignee:	nobody → Canonical Desktop Team (canonical-desktop-team)

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-16:

#8

@Sebastien. It Seems to the same bug. This one was raised first though so technically it's a duplicate of this one ;)

I am concerned by the lack of official response to any of these bugs by the Gnome team. Given that mounting shares is pretty much gvfs' sole function you'd think they'd be looking at it by now. This is a total showstopper for me with regard to using Lucid.

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-16:

#94

Can you please post you gvfs, gnome-keyring and libgnome-keyring package versions? Also, would it be possible to grab a backtrace and post it here? I'm not seeing this on my machine, though other people reported the same issue.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-16:

#9

Could you try to get a stacktrace of gvfsd-smb while it's using cpu?

Revision history for this message

Thomas Poulsen (thomas-lha66) wrote on 2010-03-16:

#10

I'm having the same problem as reported in Bug #536790.

A stacktrace of gvfsd-smb while it is using 100% CPU looks like the following:

$ pstack 5191

5191: /usr/lib/gvfs/gvfsd-smb --spawner :1.8 /org/gtk/gvfs/exec_spaw/8
(No symbols found)
0x0057d422: ???? (938d400, 7, ffffffff, 37dff4, 931add0, 37dff4)
0x0030539b: ???? (938d400, 7, ffffffff, 938d400, 7, bfb6ede4) + 60
0x002f7eff: ???? (1, 93123f0, 1, 0, 1, 804a914) + 30
0x002f861f: ???? (931b4c8, 0, 8066aab, 31fafe, 9311b40, 806a57c) + 50
0x080530ba: ???? (4, bfb6ef94, 1, 8066aab, 0, 8066aab) + 10
0x080533c6: ???? (4, bfb6ef94, bfb6efa8, b773d830, bfb6ef50, ffffffff) + 60
0x00c54bd6: ???? (8053370, 4, bfb6ef94, 8066570, 8066560, 45e0b0) + 40491078

The gvfsd-smb process was started by opening a bookmarked samba-share in
Nautilus.

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-16:

#95

>Also, would it be possible to grab a backtrace and post it here?
I am not sure how do do this.
I will try

[floki@flokic ~]$ rpm -qa | grep gvfs
gvfs-fuse-1.5.5-1.fc13.x86_64
gvfs-fuse-1.5.3-2.fc13.x86_64
gvfs-obexftp-1.5.5-1.fc13.x86_64
gvfs-archive-1.5.5-1.fc13.x86_64
gvfs-obexftp-1.5.3-2.fc13.x86_64
gvfs-1.5.5-1.fc13.x86_64
gvfs-afc-1.5.5-1.fc13.x86_64
gvfs-gphoto2-1.5.5-1.fc13.x86_64
gvfs-1.5.3-2.fc13.x86_64
gvfs-smb-1.5.5-1.fc13.x86_64
[floki@flokic ~]$

[floki@flokic ~]$ rpm -qa | grep gnome-keyring
libgnome-keyring-2.29.4-4.fc13.x86_64
gnome-keyring-pam-2.29.92-1.fc13.x86_64
gnome-keyring-2.29.92-1.fc13.x86_64
[floki@flokic ~]$

Martin Pitt (pitti) on 2010-03-16

Changed in gvfs (Ubuntu Lucid):
assignee:	Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)

Revision history for this message

In Red Hat Bugzilla #573202, Fedora (fedora-redhat-bugs) wrote on 2010-03-17:

#96

libgnome-keyring-2.29.92-git20100317.1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libgnome-keyring-2.29.92-git20100317.1.fc13

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-17:

#97

(In reply to comment #7)
> >Also, would it be possible to grab a backtrace and post it here?
> I am not sure how do do this.
> I will try
Please see http://fedoraproject.org/wiki/StackTraces#gdb, this wiki should provide you all information necessary.

> [floki@flokic ~]$ rpm -qa | grep gvfs
> gvfs-fuse-1.5.5-1.fc13.x86_64
> gvfs-fuse-1.5.3-2.fc13.x86_64
> gvfs-obexftp-1.5.5-1.fc13.x86_64
> gvfs-obexftp-1.5.3-2.fc13.x86_64
> gvfs-1.5.5-1.fc13.x86_64
> gvfs-1.5.3-2.fc13.x86_64
This is quite mess in your system. Be sure to run yum-complete-transaction or manually remove the old packages. It shouldn't make a difference though.

Also, I've built new libgnome-keyring snapshot, please test it. I still can't reproduce the problem on my machine.

Revision history for this message

Geoffrey Pursell (geoffp) wrote on 2010-03-17:

#11

I'm getting this when trying to load up a bookmark of an ssh server, which is a very common use case for me.

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-18:

#98

I reinstalled F13 form live x86_64. updated and updated libgnome-keyring form kojoi.
I is possible to see samba share from F12 computer.
( off to shares one wans opend with gedit from nautilus when clicked ).
I sama was opend from nautilus using network and select windows share and giving local ipv4 number then samba share was seen and ok.
I have not yet given permanent password fore windows share.

Usung smb: was not possible.
I shaw gvfsd-smb-brows with high cpu.
I was statting to bactrace when f13 freaze.

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-18:

#12

Stacktrace of gvfsd-smb:
1923: /usr/lib/gvfs/gvfsd-smb --spawner :1.6 /org/gtk/gvfs/exec_spaw/3
(No symbols found)
0x003d4422: ???? (93f81f0, 7, ffffffff, 587ff4, 93cbec0, 587ff4)
0x0050f32b: ???? (93f81f0, 7, ffffffff, 93f81f0, 7, bfff6794) + 60
0x00501e5c: ???? (1, 93c3978, 1, 0, 1, 804a914) + 30
0x005025c7: ???? (93cc5c8, 0, 8066aab, 5299ee, 93c33b8, 806a57c) + 50
0x080530ba: ???? (4, bfff6944, 1, 8066aab, 0, 8066aab) + 10
0x080533c6: ???? (4, bfff6944, bfff6958, b7798830, bfff6900, ffffffff) + 60
0x0059fbd6: ???? (8053370, 4, bfff6944, 8066570, 8066560, 3880b0) + 400096c8

Revision history for this message

danbuntu (danattwood) wrote on 2010-03-20:

#13

I can confirm as well that I am seeing the same problem. 2 out of three of my gvfs share will mount though the 3rd won't. All three cause 100% cpu usage.

Revision history for this message

apinunt (apinunt) wrote on 2010-03-21:

#14

I found that Samba was no longer installed, and after installing it everything now seems to work properly, and no high cpu usage.

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-21:

#99

I am afraid that I will not be able to get backtrace.
The computer was freezing when I was trying. I have seen that also in chases not related to samba.
It might be related to hardware problem.

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-22:

#100

From upstream bug report it looks like dbus might be guilty for some problems, can you please post versions of your dbus and dbus-glib packages?

Also, I've built gnome-keyring-2.29.92-2.fc13 and libgnome-keyring-2.29.92-git20100322.1.fc13, can you give them a shot too?

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-22:

#101

Created attachment 401882
top rpm -q gdb try

Still same problem.
This is F13 fully updated.
I am not good at backtraces.

>versions of your dbus and dbus-glib packages?

[floki@flokic ~]$ rpm -qa | grep dbus
dbus-x11-1.2.22-1.fc13.x86_64
dbus-libs-1.2.22-1.fc13.x86_64
dbus-1.2.22-1.fc13.x86_64
eggdbus-0.6-2.fc13.x86_64
dbus-python-0.83.0-6.fc12.x86_64
dbus-glib-debuginfo-0.84-3.fc13.x86_64
dbus-c++-0.5.0-0.11.20090203git13281b3.fc13.x86_64
python-slip-dbus-0.2.8-1.fc13.noarch
dbus-debuginfo-1.2.22-1.fc13.x86_64
dbus-glib-0.84-3.fc13.x86_64
[floki@flokic ~]$

>Also, I've built gnome-keyring-2.29.92-2.fc13 and
>libgnome-keyring-2.29.92-git20100322.1.fc13, can you give them a shot too?
[
floki@flokic ~]$ rpm -qa | grep gnome-keyring
libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64
libgnome-keyring-debuginfo-2.29.92-git20100317.1.fc13.x86_64
gnome-keyring-pam-2.29.92-2.fc13.x86_64
gnome-keyring-2.29.92-2.fc13.x86_64

floki@flokic ~]$ rpm -q libgnome-keyring
libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-22:

#102

Created attachment 401887
valgrind nautilus smb:

valgrind nautilus smb:

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-23:

#103

Oh, I should've mentioned that gvfsd-smb (or gvfsd-smb-browse) is the right process to debug, nautilus acts here just as a frontend. Sorry for that. Also see your comment 5.

If the process is still running, you can attach to it by doing `gdb /usr/libexec/gvfsd-smb-browse <PID>`. Entering "t a a bt" should give you the backtrace I'm looking for. Probably it would look like this: http://bugzilla-attachments.gnome.org/attachment.cgi?id=156584 hopefully with less number of question marks.

Revision history for this message

In Red Hat Bugzilla #573202, Flóki (flki-redhat-bugs) wrote on 2010-03-23:

#104

This works now.

Revision history for this message

In Red Hat Bugzilla #573202, Fedora (fedora-redhat-bugs) wrote on 2010-03-24:

#105

libgnome-keyring-2.29.92-git20100317.1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-24:

#106

*** Bug 576504 has been marked as a duplicate of this bug. ***

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-24:

#107

My stack:

(gdb) bt
#0 0x00007f5b97bfa283 in poll () from /lib64/libc.so.6
#1 0x00007f5b980e68f9 in ?? () from /lib64/libglib-2.0.so.0
#2 0x00007f5b980e70a5 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3 0x000000000040c0de in dbus_message_append_args ()
#4 0x000000000040c36c in dbus_message_append_args ()
#5 0x00007f5b97b3dd2d in __libc_start_main () from /lib64/libc.so.6
#6 0x0000000000407d49 in dbus_message_append_args ()
#7 0x00007fff58023728 in ?? ()
#8 0x000000000000001c in ?? ()
#9 0x0000000000000004 in ?? ()
#10 0x00007fff58023c0f in ?? ()
#11 0x00007fff58023c26 in ?? ()
#12 0x00007fff58023c30 in ?? ()
#13 0x00007fff58023c35 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) t
[Current thread is 1 (Thread 0x7f5b9a3d77c0 (LWP 5950))]

-----------------------------------------------
rpm -q libgnome-keyring
libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64

---------------------------------
top info:
5950 iranzo 20 0 273m 4972 3964 S 79.3 0.2 1:18.94 gvfsd-smb

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-25:

#108

Pablo, can you please install missing debuginfo packages and try catching a better backtrace? Please see http://fedoraproject.org/wiki/StackTraces, either way gdb should give you hint what's needed.

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-25:

#109

Download full text (9.8 KiB)

SMB connection is started choosing from Gnome's 'places' a bookmark with remembered password to connect.

stack trace doing gdb --pid=$PID, and then:
thread apply all bt full

---------------------------------------------------------------
Thread 2 (Thread 0x7fb0d0c5f710 (LWP 20557)):
#0 dbus_pending_call_block (pending=0x7fb0cc075cd0) at dbus-pending-call.c:703
        __FUNCTION__ = "dbus_pending_call_block"
#1 0x0000003b65408a03 in gkr_operation_block (op=0x7fb0cc078040) at gkr-operation.c:372
        __PRETTY_FUNCTION__ = "gkr_operation_block"
#2 0x000000000041b975 in g_vfs_keyring_lookup_password (username=0x1b5fa70 "nmt", host=0x1b5f3f0 "192.168.2.4", domain=0x0,
    protocol=<value optimized out>, object=0x0, authtype=<value optimized out>, port=0, username_out=0x7fb0d0c5e2e8, domain_out=0x7fb0d0c5e2e0,
    password_out=0x7fb0d0c5e2f0) at gvfskeyring.c:61
        pwd_data = 0x1b5fa70
        result = <value optimized out>
        plist = <value optimized out>
#3 0x00000000004098a0 in auth_callback (context=<value optimized out>, server_name=<value optimized out>, share_name=<value optimized out>,
    domain_out=0x7fb0d0c5e580 "MYGROUP", domainmaxlen=<value optimized out>, username_out=0x7fb0d0c5e480 "nmt", unmaxlen=256,
    password_out=0x7fb0d0c5e380 "", pwmaxlen=256) at gvfsbackendsmb.c:203
        in_keyring = 0
        backend = 0x1b5e020
        ask_password = <value optimized out>
        ask_user = <value optimized out>
        ask_domain = <value optimized out>
        handled = <value optimized out>
        abort = <value optimized out>
#4 0x00007fb0d755419a in SMBC_call_auth_fn (ctx=0x7fb0cc030ea0, context=<value optimized out>, server=<value optimized out>, share=<value optimized out>,
    pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:115
        workgroup = "MYGROUP\000\200\071@S;\000\000\000\240MPװ\177\000\000`\226\327װ\177\000\000\250\001\000\000\001\000\000\000\377\377\377\377\000\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000x`b", '\000' <repeats 13 times>"\360, .\a̰\177\000\000\220\067\a̰\177\000\000\000\000\000\000\000\000\000\000\341\345\200P;\000\000\000\005", '\000' <repeats 15 times>, "\005\000\000\000\260\177\000\000\240MPװ\177\000\000\030\350\305а\177\000\000\360.\a̰\177\000\000`/\a̰\177\000\000PG\a̰\177\000\000`/\a̰\177\000\000\245R\201P;\000\000\000p\224@\000\000\000\000\000PG\a̰\177\000\000`/\a̰\177\000\000\360.\a̰\177\000\000`[\a̰\177\000\000\220\067\a̰\177\000\000\360\353\305а\177\000\000\350 \242P;"...
        username = "nmt", '\000' <repeats 252 times>
        password = '\000' <repeats 255 times>
        auth_with_context_fn = <value optimized out>
#5 0x00007fb0d7554400 in SMBC_find_server (ctx=0x7fb0cc030ea0, context=0x7fb0cc075b60, server=0x7fb0cc072ef0 "192.168.2.4", share=0x7fb0cc072f60 "share",
    pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:175
        srv = <value optimized out>
        auth_called = <value optimized out>
#6 0x00007fb0d75544ed in SMBC_server_internal (ctx=<value optimized out>, context=0x7fb0cc075b60, connect...

SMB connection is started choosing from Gnome's 'places' a bookmark with remembered password to connect.

stack trace doing gdb --pid=$PID, and then:
thread apply all bt full

---------------------------------------------------------------
Thread 2 (Thread 0x7fb0d0c5f710 (LWP 20557)):
#0  dbus_pending_call_block (pending=0x7fb0cc075cd0) at dbus-pending-call.c:703
        __FUNCTION__ = "dbus_pending_call_block"
#1  0x0000003b65408a03 in gkr_operation_block (op=0x7fb0cc078040) at gkr-operation.c:372
        __PRETTY_FUNCTION__ = "gkr_operation_block"
#2  0x000000000041b975 in g_vfs_keyring_lookup_password (username=0x1b5fa70 "nmt", host=0x1b5f3f0 "192.168.2.4", domain=0x0, 
    protocol=<value optimized out>, object=0x0, authtype=<value optimized out>, port=0, username_out=0x7fb0d0c5e2e8, domain_out=0x7fb0d0c5e2e0, 
    password_out=0x7fb0d0c5e2f0) at gvfskeyring.c:61
        pwd_data = 0x1b5fa70
        result = <value optimized out>
        plist = <value optimized out>
#3  0x00000000004098a0 in auth_callback (context=<value optimized out>, server_name=<value optimized out>, share_name=<value optimized out>, 
    domain_out=0x7fb0d0c5e580 "MYGROUP", domainmaxlen=<value optimized out>, username_out=0x7fb0d0c5e480 "nmt", unmaxlen=256, 
    password_out=0x7fb0d0c5e380 "", pwmaxlen=256) at gvfsbackendsmb.c:203
        in_keyring = 0
        backend = 0x1b5e020
        ask_password = <value optimized out>
        ask_user = <value optimized out>
        ask_domain = <value optimized out>
        handled = <value optimized out>
        abort = <value optimized out>
#4  0x00007fb0d755419a in SMBC_call_auth_fn (ctx=0x7fb0cc030ea0, context=<value optimized out>, server=<value optimized out>, share=<value optimized out>, 
    pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:115
        workgroup = "MYGROUP\000\200\071@S;\000\000\000\240MPװ\177\000\000`\226\327װ\177\000\000\250\001\000\000\001\000\000\000\377\377\377\377\000\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000x`b", '\000' <repeats 13 times>"\360, .\a̰\177\000\000\220\067\a̰\177\000\000\000\000\000\000\000\000\000\000\341\345\200P;\000\000\000\005", '\000' <repeats 15 times>, "\005\000\000\000\260\177\000\000\240MPװ\177\000\000\030\350\305а\177\000\000\360.\a̰\177\000\000`/\a̰\177\000\000PG\a̰\177\000\000`/\a̰\177\000\000\245R\201P;\000\000\000p\224@\000\000\000\000\000PG\a̰\177\000\000`/\a̰\177\000\000\360.\a̰\177\000\000`[\a̰\177\000\000\220\067\a̰\177\000\000\360\353\305а\177\000\000\350 \242P;"...
        username = "nmt", '\000' <repeats 252 times>
        password = '\000' <repeats 255 times>
        auth_with_context_fn = <value optimized out>
#5  0x00007fb0d7554400 in SMBC_find_server (ctx=0x7fb0cc030ea0, context=0x7fb0cc075b60, server=0x7fb0cc072ef0 "192.168.2.4", share=0x7fb0cc072f60 "share", 
    pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:175
        srv = <value optimized out>
        auth_called = <value optimized out>
#6  0x00007fb0d75544ed in SMBC_server_internal (ctx=<value optimized out>, context=0x7fb0cc075b60, connect_if_not_found=true, 
    server=0x7fb0cc072ef0 "192.168.2.4", share=<value optimized out>, pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8, 
    in_cache=0x7fb0d0c5eb1f) at libsmb/libsmb_server.c:267
        srv = 0x0
        workgroup = 0x0
        c = 0x0
        called = {name = "\300/\a̰\177\000\000\300/\a̰\177\000", 
          scope = "`[\a̰\177", '\000' <repeats 34 times>, "\001\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000\006\000\000\000|\000\000", 
          name_type = 119}
        calling = {name = "\340\023\004̰\177\000\000;s\223װ\177\000", 
          scope = "\200\023\004̰\177\000\000R\313\307P;\000\000\000(\000\000\000\000\000\000\000p\f\025\350\000\000\000\000P6\a̰\177\000\000\340\023\004̰\177\000\000\000\000\000\000\000\000\000\000\300/\a̰\177\000", name_type = 8}
        ss = {ss_family = 2, __ss_align = 0, __ss_padding = '\000' <repeats 111 times>}
        tried_reverse = 0
        port_try_first = <value optimized out>
        port_try_next = <value optimized out>
        is_ipc = <value optimized out>
        fs_attrs = 0
        username_used = <value optimized out>
        status = <value optimized out>
        newserver = <value optimized out>
        newshare = <value optimized out>
        __FUNCTION__ = "SMBC_server_internal"
#7  0x00007fb0d75551de in SMBC_server (ctx=<value optimized out>, context=0x7fb0cc075b60, connect_if_not_found=<value optimized out>, 
    server=0x7fb0cc072ef0 "192.168.2.4", share=0x7fb0cc072f60 "share", pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8)
    at libsmb/libsmb_server.c:670
        srv = 0x0
        in_cache = false
        __FUNCTION__ = "SMBC_server"
#8  0x00007fb0d75561e4 in SMBC_stat_ctx (context=0x7fb0cc075b60, fname=0x7fb0cc062370 "smb://192.168.2.4/share", st=0x7fb0d0c5ec80)
    at libsmb/libsmb_stat.c:168
        srv = 0x0
        server = 0x7fb0cc072ef0 "192.168.2.4"
        share = 0x7fb0cc072f60 "share"
        user = 0x7fb0cc073790 "iranzo"
        password = 0x7fb0cc0413e0 ""
        workgroup = 0x7fb0cc074750 "MYGROUP"
        path = 0x7fb0cc072e90 ""
        write_time_ts = {tv_sec = 5, tv_nsec = 0}
        access_time_ts = {tv_sec = 0, tv_nsec = 254753695201}
        change_time_ts = {tv_sec = 140397393603712, tv_nsec = 140397313621664}
        size = 0
        mode = 0
        ino = 0
        frame = <value optimized out>
        __FUNCTION__ = "SMBC_stat_ctx"
#9  0x000000000040b633 in do_mount (backend=<value optimized out>, job=0x1b5d030, mount_spec=<value optimized out>, mount_source=<value optimized out>, 
    is_automount=<value optimized out>) at gvfsbackendsmb.c:575
        op_backend = 0x1b5e020
        smb_context = 0x7fb0cc075b60
        st = {st_dev = 254761504384, st_ino = 254758341034, st_nlink = 140397393603864, st_mode = 0, st_uid = 1, st_gid = 0, __pad0 = 0, 
          st_rdev = 254766231095, st_size = 0, st_blksize = 2032, st_blocks = 0, st_atim = {tv_sec = 254790318144, tv_nsec = 32}, st_mtim = {
            tv_sec = 28597152, tv_nsec = 140397313525952}, st_ctim = {tv_sec = 254790318144, tv_nsec = 32}, __unused = {28692528, 28702464, 28692528}}
        uri = 0x7fb0cc062370 "smb://192.168.2.4/share"
        res = <value optimized out>
        display_name = <value optimized out>
        debug = <value optimized out>
        debug_val = <value optimized out>
        smb_mount_spec = 0x7fb0cc017ea0
        smbc_stat = <value optimized out>
#10 0x0000000000410ec2 in g_vfs_job_run (job=0x1b5d030) at gvfsjob.c:198
        class = 0x1b5f700
#11 0x0000003b5286702b in g_thread_pool_thread_proxy (data=<value optimized out>) at gthreadpool.c:315
        task = 0x1b5d030
        pool = 0x1b53390
#12 0x0000003b52865164 in g_thread_create_proxy (data=0x1b5cdf0) at gthread.c:1893
        thread = 0x1b5cdf0
        __PRETTY_FUNCTION__ = "g_thread_create_proxy"
#13 0x0000003b51406e11 in start_thread (arg=0x7fb0d0c5f710) at pthread_create.c:301
        __res = <value optimized out>
        pd = 0x7fb0d0c5f710
        now = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140397393606416, 6505944271681342490, 140733309885504, 140397393606416, 0, 3, -6545876146535412710, 
                6503025618731256858}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <value optimized out>
        sp = <value optimized out>
        freesize = <value optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#14 0x0000003b50ce4a0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
No locals.

Thread 1 (Thread 0x7fb0d6bfa7c0 (LWP 20556)):
#0  0x0000003b50cdb283 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/poll.c:87
        __arg2 = 7
        _a3 = -1
        _a1 = 28694848
        resultvar = <value optimized out>
        __arg3 = -1
        __arg1 = 28694848
        _a2 = 7
        resultvar = <value optimized out>
        oldtype = 0
        result = <value optimized out>
#1  0x0000003b5283f8f9 in g_main_context_poll (context=0x1b52be0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>)
    at gmain.c:2904
        poll_func = 0x3b5284ca20 <IA__g_poll>
#2  g_main_context_iterate (context=0x1b52be0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2586
        max_priority = 2147483647
        timeout = -1
        some_ready = <value optimized out>
        nfds = 7
        allocated_nfds = <value optimized out>
        fds = 0x1b5d940
        __PRETTY_FUNCTION__ = "g_main_context_iterate"
#3  0x0000003b528400a5 in IA__g_main_loop_run (loop=0x1b53210) at gmain.c:2799
        self = 0x1b44520
        __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#4  0x000000000040c0de in daemon_main (argc=<value optimized out>, argv=<value optimized out>, max_job_threads=<value optimized out>, 
    default_type=0x41d883 "smb-share", mountable_name=<value optimized out>, first_type_name=0x41d883 "smb-share") at daemon-main.c:294
        var_args = {{gp_offset = 48, fp_offset = 0, overflow_arg_area = 0x7fff06f1a240, reg_save_area = 0x7fff06f1a1c0}}
        connection = <value optimized out>
        loop = <value optimized out>
        daemon = 0x1b53400
        derror = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 0, dummy3 = 0, dummy4 = 0, dummy5 = 0, padding1 = 0x3b5285aca1}
        mount_spec = 0x0
        mount_source = <value optimized out>
        error = 0x0
        res = <value optimized out>
        type = <value optimized out>
#5  0x000000000040c36c in main (argc=4, argv=0x7fff06f1a338) at daemon-main-generic.c:39
No locals.
---------------------------------------------------------------

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-26:

#110

Great, thanks. While you are in the debugger, can you please add breakpoint on auth_callback and see how many times does it break? Use "c" to continue the running process after you set up the breakpoint by "break auth_callback".

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-26:

#111

The lock happens even with the target machine not responding to ping....

attempting connection with target IP powered off, gvfs started eating all cpu as usual.

gdb --pid=$PID
break auth_callback
c

just keep 'quiet' for a long period, after killing $PID it displays:

(gdb) break auth_callback
Breakpoint 1 at 0x409600: file gvfsbackendsmb.c, line 155.
(gdb) c
Continuing.

Program received signal SIGTERM, Terminated.
0x0000003b50cdb283 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
87 int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-26:

#15

could somebody getting the issue get a stracktrace of gvfsd-smb while it's eating cpu

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-26:

#16

Changing the settings, quite some users get the issue, could be due to gnome-keyring I emailed upstream about it now

Changed in gvfs (Ubuntu Lucid):
importance:	Low → High

Revision history for this message

Martin Soto (soto255) wrote on 2010-03-26:

#17

gdb-gvfsd-smb.txt Edit (12.3 KiB, text/plain)

I already posted to Bug #532024 with my symptoms. I'm attaching a backtrace of the running gvfsd-smb process. It seems to hang while trying to contact gnome-keyring-daemon. I tried to make the backtrace as complete as possible symbol-wise, but let me know if I can provide more info. The issue is 100% reproducible here.

Revision history for this message

Martin Soto (soto255) wrote on 2010-03-26:

#18

gdb-gnome-keyring-daemon.txt Edit (4.2 KiB, text/plain)

Here is a backtrace of gnome-keyring-daemon taken while the gvfsd-smb process was hanging. I don't see anything strange here, though.

Revision history for this message

Majestyx (majestyx) wrote on 2010-03-28:

#19

no smb, no usb, but a (not really existent) fd0 ;)

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-29:

#20

The issue is rather a libgnome-keyring one and there is a change to try on bugzilla.gnome.org now which I will upload to lucid today

affects:	gvfs (Ubuntu Lucid) → libgnome-keyring (Ubuntu Lucid)
Changed in libgnome-keyring (Ubuntu Lucid):
assignee:	Martin Pitt (pitti) → Sebastien Bacher (seb128)

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-29:

#21

the lucid version has been updated with the change to try now, could the users having the issue update to this new version, restart their session and comment on the bug to say if that solves the issue or not

Revision history for this message

Launchpad Janitor (janitor) wrote on 2010-03-29:

#22

This bug was fixed in the package libgnome-keyring - 2.29.4git20100322-0ubuntu3

---------------
libgnome-keyring (2.29.4git20100322-0ubuntu3) lucid; urgency=low

  * debian/patches/01_upstream_gvfsd_cpu_use.patch:
    - upstream change which could be solving the gvfsd eating cpu issue
      (lp: #530605)
-- Sebastien Bacher <email address hidden> Mon, 29 Mar 2010 13:46:46 +0200

Changed in libgnome-keyring (Ubuntu Lucid):
status:	Triaged → Fix Released

Revision history for this message

DarrenShare (darren-moorstreet) wrote on 2010-03-29:

#23

@Sebastien

I'm still waiting for the update to come through here. I'm still on libgnome-keyring version 2.29.4git20100322-0ubuntu2.

Revision history for this message

jpfle (jpfle) wrote on 2010-03-29:

#24

Sebastien Bacher wrote:
>the lucid version has been updated with the change to try now,
>could the users having the issue update to this new version,
>restart their session and comment on the bug to say if that
>solves the issue or not

I updated to libgnome-keyring 2.29.4git20100322-0ubuntu3 and it fixed the problem. Thanks!

Revision history for this message

timosha (timosha) wrote on 2010-03-29:

#25

The bug is not completely resolved with the latest libgnome-keyring. I can open one (1) password protected samba share and are prompted for username and password. When I select "remember" forever gvfsd-smb hangs with 100% CPU load when I try to open another password protected samba share.

When I delete the key in Seahorse the whole thing starts all over again. In noticed in Seahorse that the password is stored as "use: Saved password or login" in Ubuntu 9.10 the password is store as "Network Credential" with a network icon in front of the password.

Tested this on 3 machines: Thinkpad R51 & R52 and HP dx2400.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-29:

#26

the new comment could be an another issue, could you get a stracktrace from this one, let's see how it works for the issue other users were having before and open a new one about this bug if the update works for some users

Revision history for this message

Martin Soto (soto255) wrote on 2010-03-29:

#27

gdb-gvfsd-smb.txt Edit (12.1 KiB, text/plain)

In my case, the problem persists after the update. I'm attaching a backtrace. Unfortunately, the symbols are incomplete because the -dbgsym package for gvfs-backends hasn't been updated to the current version in Lucid (1.6.0). If nobody beats me to it, I'll upload an updated backtrace when the debugging symbols become available.

Revision history for this message

axoin (axoin) wrote on 2010-03-29:

#28

the patch doesn't do anything for the problems with s/ftp. Version libgnome-keyring0:
Installiert: 2.29.4git20100322-0ubuntu3
Kandidat: 2.29.4git20100322-0ubuntu3
gvfs
Installiert: 1.6.0-0ubuntu

However, I cannot get any libgnome-keyring0-dbgsym so I can't make a new stacktrace.
I also took a look in seahorse like timosha and I have the same behaviour. Credentials are only stored as "password" and not as "network credentials".

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-29:

#29

did you restart your session before trying?

Revision history for this message

timosha (timosha) wrote on 2010-03-29:

#30

@Sebastien

I did not only restart the session on 3 machines, I rebooted them after the updates. The problem persists.

Sebastien Bacher (seb128) on 2010-03-29

Changed in libgnome-keyring (Ubuntu Lucid):
status:	Fix Released → Triaged

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-29:

#112

Thanks, so it's stuck in there. Any chance you can try the libgnome-keyring patch posted at https://bugzilla.gnome.org/show_bug.cgi?id=613399#c2 ?

Revision history for this message

Sebastien Bacher (seb128) wrote on 2010-03-29:

#31

> I did not only restart the session on 3 machines, I rebooted them after the updates. The problem persists.

seems you have some easy way to trigger the issue, could you share the steps and describe your scenario there? it could be useful to get the issue worked. do you use autologin or not? does that make a difference? is your keyring unlocking when using the share? ie did you run an application using it (seahorse, empathy, ...) before triggering the bug? do you get the issue when browsing smb shares too or only when connecting to one? do you need to add the password to the keyring before? is the issue specific to smb shares or to gvfs locations?

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-29:

#113

There's any RPM package to install that patch?

Thanks
Pablo

Revision history for this message

timosha (timosha) wrote on 2010-03-29:

#32

1) Delete all keys for smb and ftp shares in Seahorse;
2) Connect to password protected samba share #1 - You are prompted for a username and password - Enter username and password and click "remember forever" - Password protected share #1 opens now;
3) Connect to password protected samba share #2 - gvfsd-smb sleeps now with 100% CPU load;
4) Unmount password protected share #1 - reconnect to password protected share #1 - another gvfsd-smb hangs with 100% CPU load;
5) Kill the two (2) gvfsd-smb processes - Delete the password in Seahorse;
6) Go to step 1) and the scenario starts again;

Ditto for ftp, in that case gvsfd-ftp hangs/sleeps with 100% CPU load;

I do not use autologin, but will try that;
The keyring is probably not unlocking as I don't see the key icon in the taskbar;
The keyring works fine in providing a WEP key for WLAN at login;
The keyring works fine in providing credentials for aMSN;
The keyring DOES NOT WORK providing credentials for Ubuntuone;

This issue is typical for PASWORD PROTECTED smb shares, non protected shares mount fine. Ditto for ftp.

I entered the password for the keyring the first time I used it after installing Lucid. I was prompted for it;

Revision history for this message

In Red Hat Bugzilla #573202, Tomáš (tom-redhat-bugs-1) wrote on 2010-03-29:

#114

(In reply to comment #25)
> There's any RPM package to install that patch?
I've made testing scratch build, please grab the packages directly from koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2082001

Revision history for this message

timosha (timosha) wrote on 2010-03-29:

#33

Another test:

On exactly the same machine, a Thinkpad R51 - 2887, I inserted an UltrayBay with Ubuntu 9.10 on the hdd. On this installation the problem does not occur. I upgraded this installation to Lucid 10.04. The problem does not occur after the upgrade. The keys in Seahorse are stored as "Network Credentials" with the particular network icon.

Revision history for this message

axoin (axoin) wrote on 2010-03-29:

#34

sebastien, I described the same steps to reproduce already in Bug #538764 which you marked as duplicate.
timosha, I confirm the steps to reproduce and I may add that it is the same for sftp shares too.
However, my system is an upgraded 9.10 to 10.04 and it is a Thinkpad T43 and I am still expieriencing this bug.
I have also problems with ubuntuone-login
If there were -dbgsyms I could add another stacktrace, when will they be available?

Revision history for this message

jpfle (jpfle) wrote on 2010-03-29:

#35

Ok, I still have the bug. Here's how I can reproduce it:

1) Delete all keys for FTP locations in Seahorse.

2) Connect to a FTP location that is protected by password. Enter the username and the password and choose to remember forever. The location opens well.

3) I can open multiple FTP locations as described in the step 2. There's no problem. All FTP locations open well.

4) Unmount all previously open FTP locations.

5) Try to open again a FTP location previously accessed on the steps 2 or 3.

Actual result: gvfsd-smb starts using 100% CPU.

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-29:

#115

Hi

"libgnome-keyring-2.29.92-git20100322.2.fc13.i686" still presents the problem on x86, will test at home with x86_64

Regards
Pablo

Revision history for this message

axoin (axoin) wrote on 2010-03-29:

#36

gdb-gvfsd-sftp-100325_02.txt Edit (10.6 KiB, text/plain)

gvfs Version 1.6.0-0ubuntu1
libgnome-keyring 2.29.4git20100322-0ubuntu3
New gdb backtrace

Revision history for this message

axoin (axoin) wrote on 2010-03-29:

#37

gdb-gvfsd-sftp-100329.txt Edit (10.5 KiB, text/plain)

sorry, wrong attachment see new with
*

gvfs Version 1.6.0-0ubuntu1
libgnome-keyring 2.29.4git20100322-0ubuntu3
New gdb backtrace

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-03-29:

#116

With x86_64, problem persists too

Revision history for this message

timosha (timosha) wrote on 2010-03-29:

#38

I made another observation:

I have an UbuntuOne Token in my keyring. When I open Ubuntuone the process "ubuntuone-login" sleeps with 100% CPU load until I kill the process.

Revision history for this message

Garazi (garazi111) wrote on 2010-03-29:

#39

gdb-gvfsd-smb.txt Edit (12.7 KiB, text/plain)

Issue is not repared for me.
Here is a backtrace.
Tell me what to do if it is not enough explicit.

Revision history for this message

Andrew Fenn (andrewfenn) wrote on 2010-03-30:

#40

I upgraded just now and confirmed I had the latest packages described further up in the report. I rebooted then tested however I am still getting the same issues. The CPU maxes out the moment I try to connect to a samba share. This happens even if I delete the keys in seahorse.

Ken VanDine (ken-vandine) on 2010-03-30

Changed in desktopcouch (Ubuntu Lucid):
importance:	Undecided → High
Changed in gwibber (Ubuntu Lucid):
importance:	Undecided → High
status:	New → Triaged
Changed in desktopcouch (Ubuntu Lucid):
status:	New → Triaged

dobey (dobey) on 2010-03-30

tags:	added: u1-lucid
Changed in ubuntuone-client:
assignee:	nobody → Rodney Dawes (dobey)
importance:	Undecided → Critical
status:	New → In Progress

dobey (dobey) on 2010-03-30

Changed in ubuntuone-client:
status:	In Progress → Fix Committed

Launchpad Janitor (janitor) on 2010-04-01

Changed in libgnome-keyring (Ubuntu Lucid):
status:	Triaged → Fix Released

Rick Spencer (rick-rickspencer3) on 2010-04-02

Changed in libgnome-keyring (Ubuntu Lucid):
status:	Fix Released → Confirmed

Chad Miller (cmiller) on 2010-04-05

tags:

added: desktop+

Chad Miller (cmiller) on 2010-04-05

Changed in desktopcouch:
assignee:	nobody → Chad Miller (cmiller)
importance:	Undecided → Critical
status:	New → Confirmed

dobey (dobey) on 2010-04-05

Changed in ubuntuone-client:
status:	Fix Committed → Fix Released
Changed in ubuntuone-client (Ubuntu Lucid):
status:	New → Fix Released

Rick Spencer (rick-rickspencer3) on 2010-04-06

Changed in libgnome-keyring (Ubuntu Lucid):
status:	Confirmed → Fix Released

Joshua Hoover (joshuahoover) on 2010-04-06

tags:

added: package

Joshua Hoover (joshuahoover) on 2010-04-07

Changed in desktopcouch:
milestone:	none → lucid-final

Ubuntu QA Website (ubuntuqa) on 2010-04-07

tags:

added: iso-testing

Joshua Hoover (joshuahoover) on 2010-04-08

Changed in desktopcouch (Ubuntu Lucid):
milestone:	none → ubuntu-10.04

Martin Pitt (pitti) on 2010-04-09

Changed in desktopcouch (Ubuntu Lucid):
milestone:	ubuntu-10.04 → none
status:	Triaged → Invalid
Changed in gwibber (Ubuntu Lucid):
status:	Triaged → Invalid
Changed in desktopcouch:
status:	Confirmed → Invalid

Revision history for this message

In Red Hat Bugzilla #573202, Pablo (pablo-redhat-bugs) wrote on 2010-04-14:

#117

smbclient can connect and works ok while gvfsd-smb keeps using 100% of CPU until killed or a long timeout

Launchpad Janitor (janitor) on 2010-04-14

Changed in desktopcouch (Ubuntu Lucid):
status:	Invalid → Fix Released

Bug Watch Updater (bug-watch-updater) on 2010-04-17

Changed in gvfs:
status:	Unknown → Invalid

Revision history for this message

In Red Hat Bugzilla #573202, Fedora (fedora-redhat-bugs) wrote on 2010-04-19:

#118

libgnome-keyring-2.30.0-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libgnome-keyring-2.30.0-2.fc13

Revision history for this message

In Red Hat Bugzilla #573202, Fedora (fedora-redhat-bugs) wrote on 2010-04-20:

#119

libgnome-keyring-2.30.0-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update libgnome-keyring'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libgnome-keyring-2.30.0-2.fc13

Revision history for this message

In Red Hat Bugzilla #573202, Fedora (fedora-redhat-bugs) wrote on 2010-04-22:

#120

libgnome-keyring-2.30.0-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message

PM (pm77) wrote on 2010-09-10: Re: [Bug 530605] Re: gvfs-mount doesn't always work. gvfsd-smb starts using 100% cpu.

#81

Me too
> this bug affects me too
>
> --
> gvfs-mount doesn't always work. gvfsd-smb starts using 100% cpu.
> https://bugs.launchpad.net/bugs/530605
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Desktop CouchDB: Invalid
> Status in GVFS: Invalid
> Status in Ubuntu One Client: Fix Released
> Status in “desktopcouch” package in Ubuntu: Fix Released
> Status in “gwibber” package in Ubuntu: Invalid
> Status in “libgnome-keyring” package in Ubuntu: Fix Released
> Status in “ubuntuone-client” package in Ubuntu: Fix Released
> Status in “desktopcouch” source package in Lucid: Fix Released
> Status in “gwibber” source package in Lucid: Invalid
> Status in “libgnome-keyring” source package in Lucid: Fix Released
> Status in “ubuntuone-client” source package in Lucid: Fix Released
> Status in “gvfs” package in Fedora: Unknown
>
> Bug description:
> Binary package hint: gvfs
>
> Trying to mount a samba share using "gvfs-mount smb://server/home". Works
fine in Ubuntu 9.10. In the latest 10.04 alpha release this command just
hangs about 75% of the time and gvfsd-smb starts using 100% CPU until
killed. Once I kill the process I get a dialogue about the server not
responding.
>
> I have also tried using "gvfs-mount smb://server.local/home" and get the
same results.
>
> This is also reproducible using the menu Places | Connect to Server, but
browsing directly to the share in Nautilus via the Network bookmark seems to
work all the time.
>
> The share I am connecting to is on a Debian server running samba and I
have no problems connecting to this share in Windows or Ubuntu 9.10.
>
> Description: Ubuntu lucid (development branch)
> Release: 10.04
>
> gvfs:
> Installed: 1.5.4-0ubuntu1
> Candidate: 1.5.4-0ubuntu1
> Version table:
> *** 1.5.4-0ubuntu1 0
> 500 http://gb.archive.ubuntu.com lucid/main Packages
> 100 /var/lib/dpkg/status
>
> ProblemType: Bug
> Architecture: i386
> CheckboxSubmission: d6a9fb5d438b37af50efc2e4853fca15
> CheckboxSystem: edda5d4f616ca792bf437989cb597002
> Date: Tue Mar 2 11:11:29 2010
> DistroRelease: Ubuntu 10.04
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100224.1)
> NonfreeKernelModules: nvidia
> Package: gvfs 1.5.4-0ubuntu1
> ProcEnviron:
> LANG=en_GB.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-14.20-generic-pae
> SourcePackage: gvfs
> Uname: Linux 2.6.32-14-generic-pae i686
>
> [EDIT] I forgot to mention, I can't find anything in any log file that
would explain why this is happening.
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/desktopcouch/+bug/530605/+subscribe

Me too
 > this bug affects me too
>
> --
> gvfs-mount doesn't always work. gvfsd-smb starts using 100% cpu.
> https://bugs.launchpad.net/bugs/530605
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Desktop CouchDB: Invalid
> Status in GVFS: Invalid
> Status in Ubuntu One Client: Fix Released
> Status in “desktopcouch” package in Ubuntu: Fix Released
> Status in “gwibber” package in Ubuntu: Invalid
> Status in “libgnome-keyring” package in Ubuntu: Fix Released
> Status in “ubuntuone-client” package in Ubuntu: Fix Released
> Status in “desktopcouch” source package in Lucid: Fix Released
> Status in “gwibber” source package in Lucid: Invalid
> Status in “libgnome-keyring” source package in Lucid: Fix Released
> Status in “ubuntuone-client” source package in Lucid: Fix Released
> Status in “gvfs” package in Fedora: Unknown
>
> Bug description:
> Binary package hint: gvfs
>
> Trying to mount a samba share using "gvfs-mount smb://server/home". Works
fine in Ubuntu 9.10. In the latest 10.04 alpha release this command just
hangs about 75% of the time and gvfsd-smb starts using 100% CPU until
killed. Once I kill the process I get a dialogue about the server not
responding.
>
> I have also tried using "gvfs-mount smb://server.local/home" and get the
same results.
>
> This is also reproducible using the menu Places | Connect to Server, but
browsing directly to the share in Nautilus via the Network bookmark seems to
work all the time.
>
> The share I am connecting to is on a Debian server running samba and I
have no problems connecting to this share in Windows or Ubuntu 9.10.
>
> Description: Ubuntu lucid (development branch)
> Release: 10.04
>
> gvfs:
>   Installed: 1.5.4-0ubuntu1
>   Candidate: 1.5.4-0ubuntu1
>   Version table:
>  *** 1.5.4-0ubuntu1 0
>         500 http://gb.archive.ubuntu.com lucid/main Packages
>         100 /var/lib/dpkg/status
>
> ProblemType: Bug
> Architecture: i386
> CheckboxSubmission: d6a9fb5d438b37af50efc2e4853fca15
> CheckboxSystem: edda5d4f616ca792bf437989cb597002
> Date: Tue Mar 2 11:11:29 2010
> DistroRelease: Ubuntu 10.04
> EcryptfsInUse: Yes
> InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100224.1)
> NonfreeKernelModules: nvidia
> Package: gvfs 1.5.4-0ubuntu1
> ProcEnviron:
>  LANG=en_GB.UTF-8
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-14.20-generic-pae
> SourcePackage: gvfs
> Uname: Linux 2.6.32-14-generic-pae i686
>
> [EDIT] I forgot to mention, I can't find anything in any log file that
would explain why this is happening.
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/desktopcouch/+bug/530605/+subscribe

Revision history for this message

JPM (jpm) wrote on 2010-09-10:

#82

I'm having the same issue with Ubuntu 10.10 beta 32bit, installed with Alternate install image. It happened directly after a full update, without any customizations.

Bug Watch Updater (bug-watch-updater) on 2010-09-16

Changed in gvfs:
importance:	Unknown → High
status:	Invalid → Unknown

Revision history for this message

Dimitrios Ntoulas (ntoulasd) wrote on 2011-01-17:

#83

Having this problem with 10.10 Maverick.

2.6.35-25-generic #43-Ubuntu SMP Thu Jan 6 22:25:16 UTC 2011 i686 GNU/Linux

I have a server and 2 clients.

Server 10.04 Clients 10.10

One client works fine, the other has problem. Both clients updated.
Its must be some setting that cause the problem.

Bug Watch Updater (bug-watch-updater) on 2011-02-27

Changed in gvfs:
status:	Unknown → Invalid

Revision history for this message

karl (karl-sebastian-liebich) wrote on 2011-05-02:

#84

Well for this is a duplicate of Bug #551645 - I still encounter this bug.

Revision history for this message

Felix (apoapo) wrote on 2011-05-24:

#85

Yes, same here. desktopcouch-service restarts every few secs and is using 100% cpu immediately.

Revision history for this message

edvar (edvar-f) wrote on 2011-05-24:

#86

I had to uninstall Ubuntu One and all associated packages so my CPU Utilization went back to normal.
I reinstalled Ubuntu One and notice the package "desktopcouch-ubuntuone" wasn't installed this time. I suspect it was the one causing the high utilization.

Revision history for this message

edvar (edvar-f) wrote on 2011-05-24:

#87

http://ubuntuforums.org/showthread.php?t=1443281&page=2

Bug Watch Updater (bug-watch-updater) on 2017-10-27

Changed in gvfs (Fedora):
importance:	Unknown → Medium
status:	Unknown → Fix Released

Ubuntu
libgnome-keyring package

gvfs-mount doesn't always work. gvfsd-smb starts using 100% cpu.

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

	Status	Importance	Assigned to	Milestone
Ubuntu One Client	Fix Released	Critical	dobey
desktopcouch	Invalid	Critical	Chad Miller	desktopcouch lucid-final
gvfs	Invalid	High	gnome-bugs #611584
desktopcouch (Ubuntu)	Fix Released	High	Unassigned
Lucid	Fix Released	High	Unassigned
gvfs (Fedora)	Fix Released	Medium	redhat-bugs #573202
gwibber (Ubuntu)	Invalid	High	Unassigned
Lucid	Invalid	High	Unassigned
libgnome-keyring (Ubuntu)	Fix Released	High	Sebastien Bacher
Lucid	Fix Released	High	Sebastien Bacher
ubuntuone-client (Ubuntu)	Fix Released	Undecided	Unassigned
Lucid	Fix Released	Undecided	Unassigned

Ubuntulibgnome-keyring package

gvfs-mount doesn't always work. gvfsd-smb starts using 100% cpu.

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
libgnome-keyring package