Description: This problem has developed with 7.3 (latest): LO crashes when trying to Steps to Reproduce: 1. Start LO 2. Manage Templates / Import 3. try to select .ott file in Open-dialogue -> LO freezes Or: 1. Start LO 2. Open new Writer (or Calc) document 3. Try to "safe" the document on the Desktop. Save-dialogue appears -> LO freezes Actual Results: LO freezes, spinning beachball appears. Have to "force quit" LO before I can proceed with work. Expected Results: saving template or file Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: safemode [Information guessed from browser] OS: Mac OS X 12.6.2 OS is 64bit: no Note: crash also occurs in safe mode This happens with 7.3.7.2 and 7.4.3.2. I did a clean install of 7.4.3.2, i.e. deleted all the stuff in Library/Application Support. Date/Time: 2023-01-03 14:38:22.963 +0100 End time: 2023-01-03 14:38:46.514 +0100 OS Version: macOS 12.6.2 (Build 21G320) Architecture: x86_64h Report Version: 35.1 Incident Identifier: 77DE4285-BB6B-4C70-A21C-448B90F52D3B Share With Devs: Yes Data Source: Stackshots Shared Cache: 3172F8F5-C412-3210-95E0-1CFD89E01F8A slid base address 0x7ff817779000, slide 0x17779000 Shared Cache: A63AF9A2-5938-3085-9184-B6B4D8709371 slid base address 0x7ff801692000, slide 0x1692000 Command: soffice Path: /Applications/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 7.4.3.2 (7.4.3.2) Team ID: 7P5S3ZLCN7 Architecture: x86_64 Parent: launchd [1] PID: 1852 Time Since Fork: 457s Event: hang Duration: 23.55s Duration Sampled: 1.60s (process was unresponsive for 22 seconds before sampling) Steps: 16 (100ms sampling interval) Hardware model: MacBookPro16,2 Active cpus: 8 HW page size: 4096 VM page size: 4096 Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
Can you attach .ott file for testing?
Can't reproduce with: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 2; OS: Mac OS X 12.6.1; UI render: default; VCL: osx Locale: de-DE (en_US.UTF-8); UI: de-DE Calc: threaded An example file would be helpful. A crash report if available too.
Created attachment 184474 [details] Crash report As requested, this is one example of a crash report
Created attachment 184475 [details] zipped alias this alias links to a NAS folder
Dear Raal, dear Stephane, thanks for getting in touch with me. I have narrowed down the problem: I noticed that the timeouts (application was unresponsive 'forever') occured whenever the open/save dialogues referred to the Desktop folder. Eventually, I could ascertain that the timeout occurs whenever a certain alias file was in the folder that to the open/save dialogues refers to. This alias file does not link to a file on my SSD, but to a directory on our NAS server -- which is accessible only if VPN is active. So, once I start VPN and connect to NAS, LO does NOT crash. The crazy thing is that LO hangs although I do NOT select the alias in the open/save dialogues. The mere presence of the alias in the dialogue is enough to cause the timeout. I attach the alias (packed in a .zip - otherwise I cannot attach) to this bug report. yours, Wolfgang
(In reply to raal from comment #1) > Can you attach .ott file for testing? see attachment and comment in main thread
(In reply to Stéphane Guillou (stragu) from comment #2) > Can't reproduce with: > > Version: 7.4.3.2 / LibreOffice Community > Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 > CPU threads: 2; OS: Mac OS X 12.6.1; UI render: default; VCL: osx > Locale: de-DE (en_US.UTF-8); UI: de-DE > Calc: threaded > > An example file would be helpful. A crash report if available too. pls see comment and attachments in main thread
Thank you for the files. I can confirm the hang on the macOS native dialog. I just tried the following: 1. Copy "TTD SlideCasts @ NAS" from the "zipped alias" attachment to desktop 2. Open LO 7.4.3.2, click on Open File, navigate to desktop 3. Click once on "TTD SlideCasts @ NAS" The dialog becomes unresponsive for 1 minute until the "There was a problem connecting to the server" message pops up, but the dialog stays stuck and unresponsive after I dismiss it. The message pops up again periodically, until eventually (third, fourth or fifth time the dialog pops up) it gives up and dismissing the message makes the dialog responsive again. Note I _did_ need step 3 (click on the alias) to make the app unresponsive. Using Finder in the same way outside LO does not make it unresponsive. Double-clicking the alias will also make it try to access the resource, but there is some visual feedback, the message pops up earlier, and the user can still navigate elsewhere. Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 2; OS: Mac OS X 12.6.1; UI render: default; VCL: osx Locale: de-DE (en_US.UTF-8); UI: de-DE Calc: threaded
Dear Stéphane, thanks for the update. I realize I was impatient - as you describe after > 1 min LO comes "back to life". So LO did not crash - it just waits until some (file system?) process has a time-out. In an earlier comment I wrote that LO hangs 'forever'. This is not correct. I verified (again) that LO hangs although I do NOT select the alias in the open/save dialogues. Simply maneouvering to the folder where the alias resides causes this behaviour. Obviously, this differs from your observation. yours, Wolfgang
This bug has been around a very long time, marking as a DUP of bug 41987 *** This bug has been marked as a duplicate of bug 41987 ***
My guess is this. Initialization of the LO Finder dialog appears to be a fork() in the main LO process. Whenever a network resource is unavailable, that fork appears to fail to return to the main LO process, causing a hang instead of gracefully handling the situation by presenting a helpful message to the user such as "Network resource unavailable, please mount the network resource and try again", closing the Finder dialog and returning to the main LO UI which should regain the focus. The additional question to be solved would be how to manage the time it takes Finder to realize that the network resource is unavailable. As anyone who works with macOS in a networked environment knows, accessing remote files can variously take between a few seconds, and several minutes, depending on the remote file system being accessed. I doubt that the LO process can have any influence on those timeouts. I imagine that one way around this would be to use the native LO dialogs and define a shorter timeout there, but then the user would lose the convenience of the Finder dialog and obviously the UI experience.