Description: Calc systematically takes ~30 seconds to open any file, including empty ones. Fresh install of Libreoffice 7.0.4.2 on Linux Mint 19.3 Cinnamon 5.4.0-60-generic. I tested with and without Java & OpenCL, no difference. No error message when launching via terminal, except the following warning: Warning: failed to read path from javaldx The problem does not occur when starting Calc itself, only when loading an already existing file. The problem persists when starting libreoffice in Safe Mode. When first starting Calc, then opening the file, the delay appears to be shorter (~20s) and some error messages appear: (soffice:5580): Gtk-CRITICAL **: 11:07:41.656: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed Gtk-Message: 11:07:41.662: GtkDialog mapped without a transient parent. This is discouraged. Gtk-Message: 11:07:45.252: GtkDialog mapped without a transient parent. This is discouraged. Steps to Reproduce: 1. Create a new empty file "test.ods" and save it. 2. Close libreoffice. 3. Open "test.ods" Actual Results: Systematic ~30s loading time to open the file. Expected Results: Immediate file opening. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Ubuntu package version: 1:7.0.4_rc2-0ubuntu0.18.04.2 Calc: threaded
no problem in Version: 7.2.0.0.alpha0+ (x64) Build ID: 96bafa464ebdbce3ef04bec9beae5e745bb37794 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL only Linux (GTK3?) problem? Or may be only Mint's LO build problem? Can you install LibreOffice from https://libreoffice.org/download and try repeat your problem?
(In reply to Roman Kuznetsov from comment #1) Exact same problem with a reinstalled version (7.0.4) from https://libreoffice.org/download. > only Linux (GTK3?) problem? Or may be only Mint's LO build problem? I do have the impression that it is indeed related to something like that. I had already the problem with the version 6.0 (which I hoped to solve by upgrading to 7.0) and some digging then pointed to LO trying to load a library with the wrong version.
Thank you for reporting the bug. I can not reproduce the bug in 7.1.0.3
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
(In reply to Xisco Faulí from comment #5) > Thank you for reporting the bug. To be certain the reported issue is not > related to corruption in the user profile, could you please reset your > Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and > re-test? > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present I did a reset of the user profile, same issue.
Does you reproduce the issue if you launch LibreOffice from commandline with 'SAL_USE_VCLPLUGIN=gen' ?
(In reply to Xisco Faulí from comment #7) > Does you reproduce the issue if you launch LibreOffice from commandline with > 'SAL_USE_VCLPLUGIN=gen' ? Problem does not disappear when launching libreoffice with this parameter. For some reason, the problem seems to now appear with Writer as well and not only Calc. Is there a way to identify what is libreoffice trying to do when charging a document? Starting it from the terminal does not provide any information.
I was able to reproduce the problem with a new, blank spreadsheet saved to odf format. I had noticed the problem when trying to open a spreadsheet that I've had for months and had loaded quickly up until a few days ago. If I save the file in Excel 2007 format with .xlsx, close and re-open, it opens immediately as expected. "top" showed nothing unusual Steps to reproduce: 1. Open Libre Office Calc 2. Create a new spreadsheet. Save as odf. 3. Close Calc 4. Double click the file to open. Result: The blank spreadsheet takes a couple of minutes to open. ≻ time libreoffice ~/Desktop/test.ods javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx ________________________________________________________ Executed in 132.04 secs fish external usr time 3.44 secs 255.00 micros 3.44 secs sys time 0.51 secs 70.00 micros 0.51 secs LibreOffice version: 7.1.4.2 10(Build:2) System info: Operating System: Solus 4.3 KDE Plasma Version: 5.22.2 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.3 Kernel Version: 5.13.4-189.current (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 620
No repro. Opening and closing in 3,29 seconds real 0m3,290s user 0m2,119s sys 0m0,254s Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Calc: threaded
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.
I'm no longer able to reproduce this bug with LibreOffice version 7.2.4.1 in either Calc or Writer ≻ time libreoffice ~/Desktop/test.ods ________________________________________________________ Executed in 633.43 millis fish external usr time 15.81 millis 816.00 micros 14.99 millis sys time 34.85 millis 144.00 micros 34.71 millis ≻ time libreoffice ~/Desktop/test.odt ________________________________________________________ Executed in 782.76 millis fish external usr time 48.75 millis 36.61 millis 12.13 millis sys time 27.91 millis 3.90 millis 24.02 millis Thanks to all the developers that keep LibreOffice going :)
I am able to reproduce this observation. LO appears to be waiting for a network response. Any suggestion how I could find out what LO is waiting for? ### Test 1 Laptop connected to my home network Load times of empty LO documents more than one minute except for odt document. empty.odt 3s empty.odg 1m07s empty.ods 1m04s empty.odp 1m07s Opening time of LO (without opening a file): less than 3s. CPU load of LO is zero. ### Test 2 Laptop is offline (disconnected from network) Files load in less than 3 seconds. ### Test environment * Home network with FritzBox and WD MyCloud NAS connected via SAMBA * LibreOffice 7.2.5.2 * also LibreOffice 7.1.x * Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz 2.81 GHz * 16,0 GB * Network: Gigabit Ethernet * Windows 10 Home, 19043.1466 * Same results with two other laptops in my home network connected via WLAN
If is waiting for a network to respond, I was seeing recently a bug solved about searching for files that are not local but on the network. Could you try 7.3 to see if the bug is solved there?...
Today, the wait is gone! All empty.xxx files open quickly within a few seconds. Very strange. No idea what is different today except that I rebooted my laptop.
I think I know what causes the delay: My Windows default printer is a network printer connected to a Raspberry Pi that was off when it took LO a long time to start with opening a file. It seems that LO was waiting to access the printer during that long wait. When the Raspberry Pi was on, LO started within a few seconds. Details: Windows default printer is: \\http://raspberrypi:631\Canon_MP550_raw Raspberry Pi is off Open empty.ods -> takes about one minute Open File -> Printer Settings Set printer to \\raspberrypi\SKG-Laser-2 Tap printer settings button LO crashes -> that may be an unrelated problem. Der Absturzbericht wurde erfolgreich hochgeladen. Sie können den Bericht bald finden unter: https://crashreport.libreoffice.org/stats/crash_details/f4f89c82-51ca-42d7-99bf-fc526d956cd9 Start Raspberry Pi Open empty.ods -> opens fast Open File -> Printer Settings Set printer to \\raspberrypi\SKG-Laser-2 Tap printer settings button LO crashes Der Absturzbericht wurde erfolgreich hochgeladen. Sie können den Bericht bald finden unter: https://crashreport.libreoffice.org/stats/crash_details/0b11307d-407b-4b8d-9b20-2415a6436cd5 Set Windows default printer to "Microsoft print to PDF" Shutdown Raspberry Pi Open empty.ods -> LO starts fast Set Windows default printer to \\raspberrypi\SKG-Laser-2 Open empty.ods -> LO starts fast Open empty.ods -> LO starts after 24s It seems that LO doesn't wait for \\raspberrypi\SKG-Laser-2 (= mounted via SAMBA?) as long as for \\http://raspberrypi:631\Canon_MP550_raw (= mounted via http). When default printer is "Microsoft print to PDF", there is virtually no wait.
Dear mage99, 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 mage99, 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