[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug reported: https://launchpad.net/malone/bugs/31771 Affects: gimp (Ubuntu) Severity: Normal Priority: (none set) Status: Unconfirmed Description: gimp freezes, using 80% CPU, when a user attempts Open, Save As, or Print. Must kill process. gimp 2.2.2-1ubuntu libgnomevfs2-0 2.10.0-0ubuntu55 libgtk2.0-0 2.6.4-0ubuntu5 libgnomeui-02.10.0-0ubuntu1 Ubuntu (hoary) I know this is reported in several similar bugs, but here's some additional info. On our systems, this behavior happens for ldap user accounts (libnss-ldap, libpam-ldap). It _does_not_ happen for local accounts in /etc/passwd. Workaround If the ldap user has a local account entry in /etc/passwd, this bug disappears and gimp works fine. The user does not need entries in /etc/shadow or /etc/group. nsswitch.conf specifies files first: passwd: files ldap group: files ldap shadow: files ldap several related bugs: 1) https://launchpad.net/distros/ubuntu/+source/gimp/+bug/28136 2) http://bugzilla.gnome.org/show_bug.cgi?id=170367 3) http://bugzilla.gnome.org/show_bug.cgi?id=326218 4) http://bugzilla.gnome.org/show_bug.cgi?id=305206 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
ib/libbonoboui-2.so.0...done. Loaded symbols for /usr/lib/libbonoboui-2.so.0 Reading symbols from /usr/lib/libgnomecanvas-2.so.0...done. Loaded symbols for /usr/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/lib/libgnome-2.so.0...done. Loaded symbols for /usr/lib/libgnome-2.so.0 Reading symbols from /usr/lib/libgnome-keyring.so.0...done. Loaded symbols for /usr/lib/libgnome-keyring.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /usr/lib/gnome-vfs-2.0/modules/libfile.so...done. Loaded symbols for /usr/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols from /usr/lib/libfam.so.0...done. Loaded symbols for /usr/lib/libfam.so.0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread -1230439504 (LWP 10692)): #0 0xe410 in ?? () #1 0xb6a8f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0 #6 0xb7a32f57 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #7 0xb7a3351e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #8 0xb6da9f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0xb6a8fad8 in ?? () #11 0xb7a4b362 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 Previous frame inner to this frame (corrupt stack?) #0 0xb6cc324b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/bin/gimp, process 10623 [EMAIL PROTECTED]:~$ (script-fu:10624): LibGimpBase-WARNING **: script-fu: wire_read(): error > > Could you give a try to a newer version of Ubuntu, or do you need to stay > with hoary? > It will be difficult to try a different Ubuntu release. All our 50 desktops run Hoary, so even if Dapper did fix this, it wouldn't help me until I upgrade our desktops (planned for this spring). I might be able to test Dapper a little earlier than planed... but not immediately. Dane -- Dane Miller Technology Coordinator Olney Friends School Barnesville, Ohio -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: Ha! Another workaround! The problem goes away when I disable TLS/SSL in libnss_ldap.conf (but keep TLS in pam_ldap.conf to protect passwords). Add this to the workaround I posted with the initial bug report: >On our systems, this behavior happens for ldap user >accounts (libnss-ldap, libpam-ldap). It _does_not_ >happen for local accounts in /etc/passwd. Any ideas? Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Did you get the backtrace while it is eating CPU? Yes, maybe I'm doing it wrong. Here's my 2nd attempt: 1. launch gimp, Ctrl-O to open file --> frozen now (CPU 80-100%) 2. gdb gimp $(pidof gimp) gdb has taken over, CPU back to normal 3. (gdb) thread apply all bt (gdb) thread apply all bt Thread 2 (Thread -1230636112 (LWP 8749)): #0 0xe410 in ?? () #1 0xb6a5f9d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8772618, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8772618, block=1, dispatch=1, self=0x8bb1a00) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x8bb2c98) at gmain.c:2782 #8 0xb6d79f28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a5fad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8bb1a00) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xe410 in ?? () (gdb) 4. (gdb) continue CPU shoots to 100%, must kill gimp. (gdb) continue Continuing. Program received signal SIGTERM, Terminated. [Switching to Thread -1217308608 (LWP 10362)] 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 5. (gdb) thread apply all bt Thread 2 (Thread -1230496848 (LWP 10374)): #0 0xe410 in ?? () #1 0xb6a819d8 in ?? () #2 0x in ?? () #3 0x0007 in ?? () #4 0xb7906549 in poll () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7a338de in g_main_context_poll (context=0x8794700, timeout=-1, priority=2147483647, fds=0xfffc, n_fds=7) at gmain.c:2880 #6 0xb7a32f57 in g_main_context_iterate (context=0x8794700, block=1, dispatch=1, self=0x8c0e9d0) at gmain.c:2573 #7 0xb7a3351e in IA__g_main_loop_run (loop=0x877c030) at gmain.c:2782 #8 0xb6d9bf28 in link_thread_io_context () from /usr/lib/libORBit-2.so.0 #9 0xb7a8a398 in __JCR_LIST__ () from /usr/lib/libglib-2.0.so.0 #10 0xb6a81ad8 in ?? () #11 0xb7a4b362 in g_thread_create_proxy (data=0x8c0e9d0) at gthread.c:561 Previous frame inner to this frame (corrupt stack?) #0 0xb6cb524b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 (gdb) (gdb) continue Continuing. Program exited with code 01. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 31771] gimp freezes, crashes on "open", "save as", "print"
Public bug report changed: https://launchpad.net/malone/bugs/31771 Comment: > Could you install libglib2.0-0-dbg libgtk2.0-0-dbg to get a debug backtrace They are both installed: libglib2.0-0-dbg2.6.3-1 libgtk2.0-0-dbg 2.6.4-0ubuntu5 > Is that specific to gimp or does it happen with gedit too by example? This is specific to gimp. gedit behaves correctly. As do eog, gnumeric, totem, etc... In the bactrace, I noticed '/lib/tls'. Could this be related to using LDAP over TLS? I'll test without TLS. Dane -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
Me too! Exactly the same... [ 112.009494] gnome-keyring-d[5672]: segfault at 0014 eip 080759c7 esp bfc629a0 error 6 [ 113.411076] gnome-keyring-d[5786]: segfault at 0014 eip 080759c7 esp b79d6dc0 error 6 [ 319.909153] gnome-keyring-d[5977]: segfault at 0014 eip 080759c7 esp bfad3b60 error 6 [ 320.928020] gnome-keyring-d[6094]: segfault at 0014 eip 080759c7 esp b79abdc0 error 6 My hardy is currently unusable. Thanks, KD -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-keyring in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV
It's worth noting that shortly after experiencing this problem, I followed Grugnog's advice on this thread and checked out and compiled the latest version of gnome-keyring from subversion. Since then, I've had no issues, and gnome-keyring has worked like a charm. So it seems that, whether by accident or by design, this particular bug has been fixed. (I had a quick browse through its Changelog, but couldn't see anything relevant.) Ovation1357 wrote: > I've done a lot more work on this tonight and have the following > information to submit: > > Workaround > --- > This isn't really a workaround as you won't have any keyring functionality > but at least you can log in. > 1) Enable login by disabling the gnome keyring PAM Module: > # cp /etc/pam.d/gdm /etc/pam.d/gdm.old > * Edit /etc/pam.d/gdm and delete all lines which reference > 'pam_gnome_keyring.so' (Expect to find 2 lines) > 2) Restart GDM or Reboot > 3) Log in and you should get in, but obviously without the Keyring features. > > Reproduction > - > The occurrence of this bug seems most prevalent on USB, Compact Flash > (attached via IDE) and SCSI based boot devices. > 1) Use the Workaround above to be able to log in as a user. > 2) Open a terminal > 3) Run: > # echo "" | /usr/bin/gnome-keyring-manager -f --login > N.B. would normally be the user's password it crashes regardless > of what you give it. > 4) The keyring daemon should now list it's environment variables, a few > messasges, a warning and then will visibly die with a SEGV. > NOTE: Allowing gnome-keyring-daemon to daemonize itself with the '-d' option > (as it gets called from the PAM module) will surpress all useful messages > including the SEGV notification!! > > Debug > > I have attached gdb to gnome-keyring-manager and captured a full backtrace, > register info and tread backtrace at the point of SEGV. As I ran gdb pointed > at the sources for keyring-daemon I have also captured 'list'. > > On the console I get the following output: >> ** Message: adding removable location: volume_label_Ubuntu_8_04_i386 at >> /media/cdrom0 >> ** Message: adding removable location: >> volume_uuid_87cfbf2f_6fcb_42cb_95ef_92e3aec6d4f1 at / >> >> ** (gnome-keyring-daemon:6249): WARNING **: location device 'FILE' already >> registered at: / >> >> Program received signal SIGSEGV, Segmentation fault. > > It seems that gnome-keyring-daemon is being screwed up while it tries to > probe the HAL about storage - This might explain the apparent > correlation between boot disk type and whether one sees the bug. > > We die in hal_device_property() at gkr-location.c:324 > > 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name); > 324 locvol->hal_volume = TRUE; > > It seems that we might benefit from some kind of bounds check in this > code as we seem to be taking it as gospel that 'locvol' will always > return a valid address. > > The SEGV happens while executing the instruction @ 0x080759c7 - This has > been consistent throughout my old /var/log/messages files: > > 0x080759c2 : call 0x804f8e0 <[EMAIL PROTECTED]> > 0x080759c7 : movl $0x1,0x14(%eax) > 0x080759ce : jmp0x80758a5 > > > So in order to set locvol->hal_volume=TRUE we take $eax + 0x14, > dereference it and write a gboolean there. This is fine for the first > few volumes and $eax always = 0x80ca828 which I trust is the valid > address of a GkrLocationVolume structure. But when I get a SEGV $eax = 0 > (which helps me understand the fact the segfault is reported at > '0014' in /var/log/messages) - of course, 0x14 is not a vaild > address. > > The reason we SEGV'd is because g_hash_table_lookup(pv->volumes_by_name, > name) returned NULL. An educated guess tells me that NULL is probably a > valid return if 'name' wasn't found in the hash, but more investigation > needs to be done in whether a simply "if ( locvol != null)" check can be > added or whether g_hash_table_lookup() should never return NULL. > > Anyway, I've included the tee output of my gdb session which will > hopefully be of use to someone who knows more about the linux HAL. > > If anyone wants me to gather any other information let me know, but I > may need some instructions.. > > ** Attachment added: "gkd-debug-01:33:13.txt" >http://launchpadlibrarian.net/13977013/gkd-debug-01%3A33%3A13.txt > -- gnome-keyring-daemon crashed with SIGSEGV https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
Sebastien - that could well be it. I don't have a log of precisely what I did, but it boils down to roughly: - install gnome-devel - download gnome-keyring from svn - configure with prefix = /usr - install I doubt gnome-devel installs any PAM headers, so gnome-keyring probably didn't attempt to build any pam integration code. An ldd of my /usr/bin/gnome-keyring-daemon gives: linux-gate.so.1 => (0xb7f93000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f7d000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f74000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7f43000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f0d000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb7ec) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7eb) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7e74000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7dc3000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7daa000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c5b000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7c42000) /lib/ld-linux.so.2 (0xb7f94000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7c3e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c3a000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7be7000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb7be3000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7bbc000) I don't see anything mentioning PAM. But I'm a perl hacker, not a C coder, and I have no dev experience of gnome, so this may not prove a thing! Please shout if there are any tests on my setup that anybody needs me to perform. Ta, Karl Sebastien Bacher wrote: > There is no code change upstream which seem likely to do a change there, > maybe the people building from svn didn't build the pam integration code > though? > > ** Changed in: gnome-keyring (Ubuntu) >Importance: Medium => High > -- gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init() https://bugs.launchpad.net/bugs/218434 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 218434] Re: gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
> - install gnome-devel
done
> - download gnome-keyring from svn
actually used the copy I had already downloaded; my copy is at revision
1137.
> - configure with prefix = /usr
done - full output of configure is attached, but the summary is:
OPTIONAL DEPENDENCIES
PAM: no
DBus: 1.1.20
HAL: no
CONFIGURATION
SSH Agent:yes
Root Certificates:none
BUILD
Debug Build: no
Unit Tests: no
> - install
done - restarted gnome, and everything still works great. e.g. my ssh
keys were automatically unlocked as you'd expect. No crashes reported.
Hope this helps. Let me know if you need me to build and install with
PAM and / or HAL supported.
Cheerio,
Karl
>
> I believe PAM has nothing to do with this problem, except it is the
> gnome-keyring PAM module which executes 'gnome-keyring-daemon -d
> --login' . It is 'gnome-keyring-daemon' itself which crashes and
> unfortunately the -d option means it deamonizes and returns exit 0,
> before the crash occurrs causing PAM (or anything else which cares like
> gdb) to think it exited normally. Then the sneaky little bugger goes and
> dies and the only thing which seems to notice it is the kernel.
>
> The actual problem lies within the gnome-keyring-daemon code while it
> tries to manage removeable storage and you'll only hit this part of the
> code if gnome-keyring-daemon was built with HAL Support for Removable
> Devices enabled.
>
> The reason that the work-around using 'auto-login' works is that GDM
> uses a different pam config for automatic login (/etc/pam.d/gdm-
> autologin) which for some reason does not include the gnome-keyring
> module. Hence it's the same as deleting the gnome-keyring references
> from /etc/pam.d/gdm
>
> Having discussed this bug with a few knowledgable colleagues the
> concensus is that regardless of why g_hash_table_lookup() returns null
> or whether it ever should, we should always check the return code:
>
> at hal_device_property() in gkr-location.c
> 323 locvol = g_hash_table_lookup (pv->volumes_by_name, name);
> 324 locvol->hal_volume = TRUE;
>
> Between 323 and 324 we need a check that 'locvol' is not null before using it
> as an address.
> If g_hash_table_lookup should never return 'null' then perhaps an
> 'assert(locvol != null)' should be added, but if 'null' is a valid retun then
> we need extra code to check it and handle it within this function, the
> simplest being 'if (locvol != null ) { locvol->hal_volume=TRUE; }'
>
** Attachment added: "config-output.txt"
http://launchpadlibrarian.net/13988714/config-output.txt
--
gnome-keyring-daemon crashed with SIGSEGV in location_manager_hal_init()
https://bugs.launchpad.net/bugs/218434
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126333] Re: [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding
I have a relatively unique setup in that I currently have three sound 'devices' running on my machine: - an onboard VIA soundcard. Relevant entry from lspci: 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) - An external USB Terratec 'aureon' sound device. Relevant entry from lsusb: '00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)' - An external USB Creative 'xmod' sound device. Relevant entry from lsusb: 'Bus 003 Device 006: ID 041e:30d0 Creative Technology, Ltd' I get all sorts of weird and wonderful behavious with this arrangement, and they're different depending upon which soundcard I'm using. First of all, the gnome-volume-control segfaults the moment I try to run it. (You'll probably want an apport or similar trace from this. I'll sort that out shortly. But I need to learn how to use these tools first, which I'll do when I'm not being paid by somebody else for my time...) The VIA works reliably in all circumstances. In particular, the volume up and down keys on my keyboard work as expected if System -> Preferences -> Sounds is set to use that device by default. When I'm using the terratec box as default, keyboard shortcuts have the desired effect upon the volume, but the pop-up volume control display is erratic; the volume bar leaps all over the place with each change in volume. The volume may have just been set to 20%, but it will show 100%, then with another change the display will leap to 0%. When I'm using the xmod box as default (my preferred arrangement) then it's even stranger; the displayed volume leaps up and down erratically in the same way as the terratec device (terratic? ;) ) above, but the actual volume setting also does the same. I can hear this, but I can also quantify this visually if I have the gnome alsa mixer open at the same time; the volume bar leaps up and down. But even worse, the balance bar, as well as the actual balance setting, leaps about the place too. I should add that changing settings using the gnome alsa mixer 'gnome- alsamixer 0.9.7~cvs.20060916.ds.1-1' works reliably and as expected on all of my sound devices. I agree that this is a low priority issue; certainly not a showstopper, but I'd love to get this fixed, so I'm very happy to perform any tests anybody requests of me to help out. Thanks, Karl Dane -- [GUTSY] Regression - Volume Control using gnome panel applet and keyboard shortcut alternates mute / % volume during sliding https://bugs.launchpad.net/bugs/126333 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 254165] [NEW] gdm Select Session key shortcuts not consistent
Public bug reported: Binary package hint: gdm The "Select Session" key shortcuts are inconsistent. When you wish to select your session, from the login prompt you press ALT+O (? for options), then the next shortcut you press is without the ALT key , then you have to press ALT+[num] to select session, then ALT+T for "Just this Session" (or ALT+[x] for make default). It seems inconsistent that the second shortcut is pressed without the ALT key, when most shortcut keys that are underlined are pressed with the ALT+key combo. Obviously, this is low priority. I'm not sure if I'm correct with those keys above either, because I'd have to log out to check. It goes ALT, no ALT, ALT, ALT. Ubuntu 8.04.1 GDM 2.20.7-0ubuntu1.1 ** Affects: gdm (Ubuntu) Importance: Undecided Status: New -- gdm Select Session key shortcuts not consistent https://bugs.launchpad.net/bugs/254165 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 432794] Re: gnome-panel freeze/infinite loop/memory leak
This may be a complete coincidence, but while I was investigating this problem, I discovered that my ntfs partition was hibernated. Dropped into windows briefly and properly shut it down, and now my gnome-panel is behaving itself. -- gnome-panel freeze/infinite loop/memory leak https://bugs.launchpad.net/bugs/432794 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
