> Le mardi 30 octobre 2007 à 17:13 +0100, =?UTF-8?Q? Andr=C3=A9?= Heynatz
> a écrit :
>> Package: gedit
>> Version: 2.20.3-1
>>
>> I have a hang as well. It happens not on the first save, but after
>> having changed the text file. I save to a remote filesystem with type
>> CIFS, options set: rw,user,noauto,username=<myusername>. The
>> filesystem is mounted.
>>
>> gdb backtrace after stopping the hang with CTRL-C:
>>
>> $ gdb gedit
>> GNU gdb 6.6.90.20070912-debian
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "i486-linux-gnu"...
>> Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
>> (gdb) set pagination 0
>> (gdb) run borders_around_figures.txt
>> Starting program: /usr/bin/gedit borders_around_figures.txt
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0xb6dd98c0 (LWP 15291)]
>>
>> Program received signal SIGINT, Interrupt.
>> [Switching to Thread 0xb6dd98c0 (LWP 15291)]
>> 0xb7f74410 in __kernel_vsyscall ()
>> (gdb) bt
>> #0 0xb7f74410 in __kernel_vsyscall ()
>> #1 0xb73f61c7 in syscall () from /lib/i686/cmov/libc.so.6
>> #2 0xb7470823 in flistxattr () from /lib/libattr.so.1
>> #3 0xb746fa7a in attr_copy_fd () from /lib/libattr.so.1
>> #4 0x0807a18f in save_existing_local_file (lsaver=0x81b9ac0) at
>> gedit-local-document-saver.c:435
>> #5 0xb74a1936 in ?? () from /usr/lib/libglib-2.0.so.0
>> #6 0x081b9ac0 in ?? ()
>> #7 0xb7e2f8ac in __pthread_mutex_unlock_usercnt () from
>> /lib/i686/cmov/libpthread.so.0
>> #8 0xb74a11c6 in g_main_context_dispatch () from
>> /usr/lib/libglib-2.0.so.0
>> #9 0xb74a4552 in ?? () from /usr/lib/libglib-2.0.so.0
>> #10 0x0811cb70 in ?? ()
>> #11 0xffffff9c in ?? ()
>> #12 0x0833c130 in ?? ()
>> #13 0x00000000 in ?? ()
>
> This is an entirely different issue than that of the initial bug. It
> looks like some libattr operation is hanging on CIFS filesystems.
>
> Nathan, what do you think? I'm tempted to reassign this to the kernel.
I tend to agree. Is this on i386-based hardware? Guess so as there's
references
to 486 and 686 in the gdb stack trace - in which case, this is a very
commonly
exercised code path - all distributions, all local filesystems would go
through this
code, so likely CIFS is involved. I came across this in the git log on
fs/cifs/xattr.c:
Author: Steve French <[EMAIL PROTECTED]>
Date: Fri Apr 21 18:17:42 2006 +0000
[CIFS] [CIFS] Do not take rename sem on most path based calls (during
building of full path) to avoid hang rename/readdir hang
Reported by Alan Tyson
Signed-off-by: Steve French <[EMAIL PROTECTED]>
Could be related, could be not - I assume this problem is not observed when
using a local filesystem like xfs/ext3?
cheers.
--
Nathan
