Bug 1021572 - LibreOffice falls into uninterruptible sleep (D state) when using Samba
LibreOffice falls into uninterruptible sleep (D state) when using Samba
Status: CLOSED DUPLICATE of bug 885156
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
18
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-21 10:34 EDT by Berthault
Modified: 2013-10-21 11:52 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-21 11:52:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Berthault 2013-10-21 10:34:00 EDT
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 11:31:34 EDT
$ 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 11:52:33 EDT

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

Note You need to log in before you can comment on or make changes to this bug.