Bug 1021572

Summary: LibreOffice falls into uninterruptible sleep (D state) when using Samba
Product: [Fedora] Fedora Reporter: Berthault <Philippe.Berthault>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: caolanm, dtardon, erack, ltinkl, mstahl, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-21 15:52:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Berthault 2013-10-21 14:34:00 UTC
Description of problem:
When I open a document from a Windows filesystem mounted by using Samba, then very often LibreOffice falls into uninterruptible sleep ('D' state) and I have to reboot my system to be able to use LibreOffice again.

This bug occurs only with LibreOffice and when using Samba. When I open other Windows file type mounted on Samba (e.g. pdf with Evince, etc.), then all is right.

Version-Release number of selected component (if applicable):
Fedora 18 (with latest update), kernel 3.11.4-101.fc18.i686
libreoffice-writer-3.6.7.2-4.fc18.i686
samba-client-4.0.9-1.fc18.i686
samba-libs-4.0.9-1.fc18.i686
samba-common-4.0.9-1.fc18.i686

How reproducible:
Try to open several times a PowerPoint or a Word file from a Windows filesystem mounted with Samba.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
$ ps -felTww
F S UID    PID  SPID  PPID  C PRI NI ADDR SZ WCHAN  STIME TTY     TIME CMD
...
0 S 1000 12068 12068     1  0  80  0 -  8859 futex_ 15:01 ?   00:00:00 /usr/lib/libreoffice/program/oosplash
1 S 1000 12068 12078     1  0  80  0 -  8859 futex_ 15:01 ?   00:00:00 /usr/lib/libreoffice/program/oosplash
1 S 1000 12068 12082     1  0  80  0 -  8859 wait   15:01 ?   00:00:00 /usr/lib/libreoffice/program/oosplash
0 D 1000 12083 12083 12068  0  80  0 - 53887 sleep_ 15:01 ?   00:00:01 /usr/lib/libreoffice/program/soffice.bin
1 S 1000 12083 12084 12068  0  80  0 - 53887 futex_ 15:01 ?   00:00:00 /usr/lib/libreoffice/program/soffice.bin
1 S 1000 12083 12107 12068  0  80  0 - 53887 skb_re 15:01 ?   00:00:00 /usr/lib/libreoffice/program/soffice.bin
1 S 1000 12083 12108 12068  0  80  0 - 53887 poll_s 15:01 ?   00:00:00 /usr/lib/libreoffice/program/soffice.bin
1 S 1000 12083 12110 12068  0  80  0 - 53887 poll_s 15:01 ?   00:00:00 /usr/lib/libreoffice/program/soffice.bin
1 S 1000 12083 12111 12068  0  80  0 - 53887 futex_ 15:01 ?   00:00:00 /usr/lib/libreoffice/program/soffice.bin
...

Comment 1 Berthault 2013-10-21 15:31:34 UTC
$ ps -le
0 S  1000  2081  2081     1  0  80   0 -  8859 pipe_w ? oosplash
1 S  1000  2081  2091     1  0  80   0 -  8859 futex_ ? oosplash
1 S  1000  2081  2095     1  0  80   0 -  8859 wait   ? oosplash

0 D  1000  2096  2096  2081  0  80   0 - 53820 sleep_ ? soffice.bin
1 S  1000  2096  2097  2081  0  80   0 - 53820 futex_ ? soffice.bin
1 S  1000  2096  2099  2081  0  80   0 - 53820 skb_re ? OfficeIPCThread
1 S  1000  2096  2100  2081  0  80   0 - 53820 poll_s ? soffice.bin
1 S  1000  2096  2102  2081  0  80   0 - 53820 poll_s ? soffice.bin
1 S  1000  2096  2103  2081  0  80   0 - 53820 futex_ ? soffice.bin

$ cat /proc/2081/stack 
[<c055d2dd>] pipe_wait+0x4d/0x70
[<c055da3e>] pipe_read+0x27e/0x440
[<c05559fa>] do_sync_read+0x6a/0xa0
[<c05566c9>] vfs_read+0x89/0x160
[<c055691f>] SyS_read+0x4f/0x90
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2091/stack 
[<c049e94a>] futex_wait_queue_me+0xda/0x130
[<c049f018>] futex_wait+0x168/0x270
[<c04a0a42>] do_futex+0x112/0x960
[<c04a132b>] SyS_futex+0x9b/0x140
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2095/stack 
[<c044ab69>] do_wait+0x1a9/0x1f0
[<c044ba4d>] SyS_wait4+0x6d/0xe0
[<c044baec>] SyS_waitpid+0x2c/0x30
[<c0997ed7>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff

$ cat /proc/2096/stack 
[<c0506a0d>] sleep_on_page_killable+0xd/0x40
[<c0506958>] __lock_page_killable+0x78/0x80
[<c0508c8d>] generic_file_aio_read+0x41d/0x6f0
[<f9081b74>] fuse_file_aio_read+0xb4/0xe0 [fuse]
[<c05559fa>] do_sync_read+0x6a/0xa0
[<c05566c9>] vfs_read+0x89/0x160
[<c0556a8a>] SyS_pread64+0x9a/0xc0
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2097/stack 
[<c049e94a>] futex_wait_queue_me+0xda/0x130
[<c049f018>] futex_wait+0x168/0x270
[<c04a0a42>] do_futex+0x112/0x960
[<c04a132b>] SyS_futex+0x9b/0x140
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2099/stack 
[<c08a5c34>] __skb_recv_datagram+0x364/0x3f0
[<c08a5cf6>] skb_recv_datagram+0x36/0x40
[<c093f285>] unix_accept+0x65/0x100
[<c0899b92>] SYSC_accept4+0xe2/0x210
[<c089aacf>] SyS_accept4+0x1f/0x30
[<c089b4a3>] SyS_socketcall+0x163/0x300
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2100/stack
[<c05666c5>] poll_schedule_timeout+0x45/0xb0
[<c056797e>] do_sys_poll+0x37e/0x520
[<c0567bca>] SyS_poll+0x5a/0xd0
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2102/stack
[<c05666c5>] poll_schedule_timeout+0x45/0xb0
[<c056797e>] do_sys_poll+0x37e/0x520
[<c0567bca>] SyS_poll+0x5a/0xd0
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

$ cat /proc/2103/stack
[<c049e94a>] futex_wait_queue_me+0xda/0x130
[<c049f018>] futex_wait+0x168/0x270
[<c04a0a42>] do_futex+0x112/0x960
[<c04a132b>] SyS_futex+0x9b/0x140
[<c099f20d>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

Comment 2 Stephan Bergmann 2013-10-21 15:52:33 UTC

*** This bug has been marked as a duplicate of bug 885156 ***