Bug 113259 - soffice --convert-to hangs on Windows Server 2016 when called multiple times
Summary: soffice --convert-to hangs on Windows Server 2016 when called multiple times
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-19 09:04 UTC by mif
Modified: 2020-02-17 02:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Debug soffice convert process (58.30 KB, text/plain)
2017-10-31 10:31 UTC, mif
Details
Debug soffice's first convert process (58.41 KB, text/plain)
2017-10-31 10:36 UTC, mif
Details
Debug soffice's second convert process (14.23 KB, text/plain)
2017-10-31 10:38 UTC, mif
Details
Debug soffice's first working convert process (36.19 KB, text/plain)
2017-10-31 11:00 UTC, mif
Details
Debug soffice's second working convert process (58.58 KB, text/plain)
2017-10-31 11:00 UTC, mif
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mif 2017-10-19 09:04:44 UTC
Description:
We convert docx documents to pdf through LibreOffice by next command: soffice --headless --convert-to pdf <input_doc> --outdir <output_dir>

All works correct on several machines (Windows 7, somde distribs fo Linux) but on server with Windows Server 2016 Standard (10.0.14393) processes soffice.bin hangs if I call this command several times (even twice in short time).

My research show me next. If second soffice.bin process starts when first already working they hangs both (~20 and 37 MB in memory). First process generate pdf successfully, but second (end other next processes) not even read source docx files. 

Temporary resolution is to run converting process with next command: soffice "-env:UserInstallation=file:///C:/Windows/Temp/<unique_number>/" --headless --convert-to pdf <source_file> --outdir <output_dir>

Need that everyone soffice watch to unique temp folder.

Steps to Reproduce:
1.Install LibreOffice 5.4.1.2 on Windows Server 2016 Standrad (x64)
2. run twice command to convert docx file to pdf: soffice --headless --convert-to pdf <input_doc> --outdir <output_dir>


Actual Results:  
All current processes hangs and new processes will hangs too. Need to kill it through Task Manager or command taskkill /IM soffice /f

Expected Results:
Convert files correctly on every call


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299
Comment 1 Mike Kaganski 2017-10-19 10:16:53 UTC
The bug I added to See Also (bug#38915) might be the issue. It was addressed somewhat in master toward 6.0; still, the bug#38915 comment 34 is still actual, and testing and feedback is helpful. Especially if you can reliably reproduce this, and can check if it's solved or not.
Comment 2 mif 2017-10-20 08:49:51 UTC
(In reply to Mike Kaganski from comment #1)
> The bug I added to See Also (bug#38915) might be the issue. It was addressed
> somewhat in master toward 6.0; still, the bug#38915 comment 34 is still
> actual, and testing and feedback is helpful. Especially if you can reliably
> reproduce this, and can check if it's solved or not.

I installed this build (http://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/2017-10-20_01.29.13/libo-master64~2017-10-20_01.29.13_LibreOfficeDev_6.0.0.0.alpha1_Win_x64.msi) and problem still exists. Processes use 26MB (first process which convert docx to pdf) and 17MB (second proc. which hangs on load) of memory.
Comment 3 Mike Kaganski 2017-10-20 09:31:36 UTC
(In reply to mif from comment #2)
> I installed this build
> (http://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/2017-10-20_01.
> 29.13/libo-master64~2017-10-20_01.29.13_LibreOfficeDev_6.0.0.0.
> alpha1_Win_x64.msi) and problem still exists. Processes use 26MB (first
> process which convert docx to pdf) and 17MB (second proc. which hangs on
> load) of memory.

Ah! a pity.

I'd be of course glad if you could also debug it somehow... like installing WinDBG, and attaching to the *first* process (that had successfully converted to PDF but failed to exit) to see where the first thread stays (stack trace)... if possible? Because it's impossible for me to reproduce that on my system. It's always great if someone can assist in catching a tricky problem!

Please don't get that as something offending, like that I want you to do my part. Of course, if you don't want to do that, it's absolutely OK :)
Comment 4 mif 2017-10-31 10:31:19 UTC
Created attachment 137400 [details]
Debug soffice convert process

Result file of debugging next command: soffice --headless --convert-to pdf C:\dbg\7B350F268D6449C7807B6C943BE9BC46.docx --outdir C:\dbg
Comment 5 mif 2017-10-31 10:36:50 UTC
Created attachment 137401 [details]
Debug soffice's first convert process

Result file of debugging of first soffice process in a next batch file:

start "" windbg -g -o soffice --headless --convert-to pdf C:\Interin\7B350F268D6449C7807B6C943BE9BC46.docx --outdir C:\Interin
start "" windbg -g -o soffice --headless --convert-to pdf C:\Interin\0F46980CFE134818931C4A48AE5521EE.docx --outdir C:\Interin

Other soffice process running parallel. This process freeze on 13:28:40. In status bar was written: "debugee running". On 13:29:07 I press Ctrl+Break
Comment 6 mif 2017-10-31 10:38:40 UTC
Created attachment 137402 [details]
Debug soffice's second convert process
Comment 7 mif 2017-10-31 10:41:53 UTC
Comment on attachment 137402 [details]
Debug soffice's second convert process

Debug soffice's second convert process

Result file of debugging of second soffice process in a next batch file:

start "" windbg -g -o soffice --headless --convert-to pdf C:\Interin\7B350F268D6449C7807B6C943BE9BC46.docx --outdir C:\Interin
start "" windbg -g -o soffice --headless --convert-to pdf C:\Interin\0F46980CFE134818931C4A48AE5521EE.docx --outdir C:\Interin

Other soffice process running parallel. This process freeze on 13:28:34. Last lines appears when I break parallel debugging process.

In results process not created pdf file.
Comment 8 mif 2017-10-31 10:42:29 UTC
Is this enough?
Comment 9 mif 2017-10-31 11:00:00 UTC
Created attachment 137403 [details]
Debug soffice's first working convert process

Debug of first convert process in next batch file:

start "" windbg -g -o soffice -env:UserInstallation=file:///C:/dbg/1/ --headless --convert-to pdf C:\dbg\0F46980CFE134818931C4A48AE5521EE.docx --outdir C:\dbg
start "" windbg -g -o soffice -env:UserInstallation=file:///C:/dbg/2/ --headless --convert-to pdf C:\dbg\7B350F268D6449C7807B6C943BE9BC46.docx --outdir C:\dbg

All works like a charm. In result - correct pdf file.
Comment 10 mif 2017-10-31 11:00:33 UTC
Created attachment 137404 [details]
Debug soffice's second working convert process

Debug of second convert process in next batch file:

start "" windbg -g -o soffice -env:UserInstallation=file:///C:/dbg/1/ --headless --convert-to pdf C:\dbg\0F46980CFE134818931C4A48AE5521EE.docx --outdir C:\dbg
start "" windbg -g -o soffice -env:UserInstallation=file:///C:/dbg/2/ --headless --convert-to pdf C:\dbg\7B350F268D6449C7807B6C943BE9BC46.docx --outdir C:\dbg

All works like a charm. In result - correct pdf file.
Comment 11 Mike Kaganski 2017-11-05 02:34:17 UTC
(In reply to mif from comment #8)

Unfortunately, the data doesn't include the backtrace. Please refer to https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg for instructions (I'm sorry I didn't linked to that page from start). Please don't forget the "Attach Symbol Sources to Debug Tool" section.
Comment 12 Xisco Faulí 2018-01-09 11:09:02 UTC
(In reply to Mike Kaganski from comment #11)
> (In reply to mif from comment #8)
> 
> Unfortunately, the data doesn't include the backtrace. Please refer to
> https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg for
> instructions (I'm sorry I didn't linked to that page from start). Please
> don't forget the "Attach Symbol Sources to Debug Tool" section.

Setting to NEEDINFO until the correct backtrace is provided.
Comment 13 Vladimir 2018-06-01 10:13:41 UTC
I have the same problem with LibreOffice 6.0.3.2 (x64) on Windows 10.
Comment 14 Vladimir 2018-06-04 15:20:54 UTC
 soffice --convert-to don't hangs on Windows 10, if quickstart.exe run (LibreOffice version 6.0.4).
Comment 15 Neil Youngman 2018-07-25 11:02:56 UTC
I can reproduce a hang on an RHEL7 box. 

Are the following gdb backtraces in nay way helpful? The last one looks corrupt.

What else do you need to trace this?


$ ps auxww | grep '[l]ibre'
neily    40304  0.0  0.0 297160  2324 pts/0    Sl+  10:54   0:00 /opt/libreoffice5.4/program/oosplash --convert-to pdf /tmp/hamlet250.docx
neily    40321 78.7  1.7 1029636 139100 pts/0  Rl+  10:54   0:18 /opt/libreoffice5.4/program/soffice.bin --convert-to pdf /tmp/hamlet250.docx
neily    40379  0.0  0.0 149696  2308 pts/3    Sl+  10:54   0:00 /opt/libreoffice5.4/program/oosplash --convert-to pdf /tmp/test250.docx

$ gdb /opt/libreoffice5.4/program/oosplash 40304
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
Copyright (C) 2013 Free Software Foundation, Inc.
...
(gdb) bt
#0  0x00007f467e698ab2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /usr/lib64/libpthread.so.0
#1  0x00007f467f2d551e in osl_waitCondition ()
   from /opt/libreoffice5.4/program/libuno_sal.so.3
#2  0x00007f467f2dce68 in osl_joinProcessWithTimeout ()
   from /opt/libreoffice5.4/program/libuno_sal.so.3
#3  0x0000000000406e3f in sal_main_with_args ()
#4  0x0000000000403cca in main ()





$ gdb /opt/libreoffice5.4/program/soffice.bin 40321
...
(gdb) bt
#0  0x00007f7cbdacff27 in pthread_join () from /usr/lib64/libpthread.so.0
#1  0x00007f7cc1ae9213 in desktop::RequestHandler::Disable() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#2  0x00007f7cc1ac4cf3 in desktop::Desktop::DeInit() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#3  0x00007f7cc2ad6c03 in DeInitVCL() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#4  0x00007f7cc2ad7a4b in ImplSVMain() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#5  0x00007f7cc2ad7ab2 in SVMain() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#6  0x00007f7cc1af1e9d in soffice_main ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#7  0x000000000040075b in main ()



$ gdb /opt/libreoffice5.4/program/soffice.bin 40379
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
Copyright (C) 2013 Free Software Foundation, Inc.
...
(gdb) bt
#0  0x00007fe4dd88699d in ?? ()
#1  0x0000000000000000 in ?? ()
Comment 16 Neil Youngman 2018-07-25 13:44:05 UTC
Checking the above for consistency I see the "corrupt" backtrace is due to passing gdb the wrong binary.

Repeating it, more carefully ....

$ ps auxww | grep '[l]ibre'
neily    64802  0.0  0.0 297160  2324 pts/0    Sl+  13:37   0:00 /opt/libreoffice5.4/program/oosplash --convert-to pdf /tmp/hamlet250.docx
neily    64819 79.6  1.7 1099548 136680 pts/0  Sl+  13:37   0:28 /opt/libreoffice5.4/program/soffice.bin --convert-to pdf /tmp/hamlet250.docx
neily    64953  0.0  0.0 149696  2312 pts/3    Sl+  13:37   0:00 /opt/libreoffice5.4/program/oosplash --convert-to pdf /tmp/test250.docx


$ gdb /opt/libreoffice5.4/program/oosplash 64802
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
...
(gdb) bt
#0  0x00007ff399705ab2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /usr/lib64/libpthread.so.0
#1  0x00007ff39a34251e in osl_waitCondition ()
   from /opt/libreoffice5.4/program/libuno_sal.so.3
#2  0x00007ff39a349e68 in osl_joinProcessWithTimeout ()
   from /opt/libreoffice5.4/program/libuno_sal.so.3
#3  0x0000000000406e3f in sal_main_with_args ()
#4  0x0000000000403cca in main ()



$ gdb /opt/libreoffice5.4/program/soffice.bin 64819 
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
...
(gdb) bt
#0  0x00007fe15fbddf27 in pthread_join () from /usr/lib64/libpthread.so.0
#1  0x00007fe163bf7213 in desktop::RequestHandler::Disable() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#2  0x00007fe163bd2cf3 in desktop::Desktop::DeInit() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#3  0x00007fe164be4c03 in DeInitVCL() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#4  0x00007fe164be5a4b in ImplSVMain() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#5  0x00007fe164be5ab2 in SVMain() ()
   from /opt/libreoffice5.4/program/libmergedlo.so
#6  0x00007fe163bffe9d in soffice_main ()
   from /opt/libreoffice5.4/program/libmergedlo.so



$ gdb /opt/libreoffice5.4/program/oosplash 64953
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7
...
(gdb) bt
#0  0x00007f34438b099d in read () from /usr/lib64/libc.so.6
#1  0x0000000000407ab6 in sal_main_with_args ()
#2  0x0000000000403cca in main ()
(gdb)
Comment 17 Xisco Faulí 2018-10-18 11:39:28 UTC
Hi Neil Youngman,
Since your patch is libreoffice5.4 I guess you're using LibreOffice 5.4.X
The latest patches for bug 38915 are included in 6.0.1 or higher

Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 18 Neil Youngman 2018-10-18 13:08:43 UTC
This still does not work correctly, but it no longer hangs. I have raised bug 120676 as I regard the new behaviour as a separate bug.
Comment 19 Buovjaga 2018-12-27 17:16:40 UTC
(In reply to Neil Youngman from comment #18)
> This still does not work correctly, but it no longer hangs. I have raised
> bug 120676 as I regard the new behaviour as a separate bug.

Mike committed a patch for this bug a couple of days ago.

mif: I wonder if the patch helps with your original problem? The only daily build fresh enough to try is at Tinderbox 39 currently: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/
Comment 20 Xisco Faulí 2019-02-07 20:34:35 UTC
(In reply to Buovjaga from comment #19)
> (In reply to Neil Youngman from comment #18)
> > This still does not work correctly, but it no longer hangs. I have raised
> > bug 120676 as I regard the new behaviour as a separate bug.
> 
> Mike committed a patch for this bug a couple of days ago.
> 
> mif: I wonder if the patch helps with your original problem? The only daily
> build fresh enough to try is at Tinderbox 39 currently:
> https://dev-builds.libreoffice.org/daily/master/Win-x86@39/

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 21 Buovjaga 2019-02-08 08:15:38 UTC
(In reply to Buovjaga from comment #19)
> (In reply to Neil Youngman from comment #18)
> > This still does not work correctly, but it no longer hangs. I have raised
> > bug 120676 as I regard the new behaviour as a separate bug.
> 
> Mike committed a patch for this bug a couple of days ago.
> 
> mif: I wonder if the patch helps with your original problem? The only daily
> build fresh enough to try is at Tinderbox 39 currently:
> https://dev-builds.libreoffice.org/daily/master/Win-x86@39/

More Tinderboxes are working now: https://dev-builds.libreoffice.org/daily/master/?C=M&O=D
Comment 22 QA Administrators 2020-01-17 03:36:25 UTC Comment hidden (obsolete)
Comment 23 QA Administrators 2020-02-17 02:33:36 UTC
Dear mif,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp