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
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.
(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.
(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 :)
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
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
Created attachment 137402 [details] Debug soffice's second convert process
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.
Is this enough?
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.
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.
(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.
(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.
I have the same problem with LibreOffice 6.0.3.2 (x64) on Windows 10.
soffice --convert-to don't hangs on Windows 10, if quickstart.exe run (LibreOffice version 6.0.4).
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 ?? ()
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)
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.
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.
(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/
(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
(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
Dear mif, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
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