Description: Copying and pasting, and then copying again causes LibreOffice Calc to crash Steps to Reproduce: Copy using Command-C Paste using enter Copy again from the same cell just pasted using Command-C Boom Actual Results: Crashes Expected Results: Shouldn't crash Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: sv-SE (en_AU.UTF-8); UI: en-US Calc: threaded
Please test in safe mode, Menu/Help/Restart in Safe Mode
Confirm Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c39e4f6b8a942680bc7250177c34fd034a0605e0 CPU threads: 8; OS: macOS 14.3; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to m_a_riosv from comment #1) > Please test in safe mode, Menu/Help/Restart in Safe Mode Immediately reproducible with any blank spreadsheet, in both normal mode and safe mode. Create new spreadsheet Enter something in a cell Copy that cell Move to different cell and push enter Copy that cell Boom
What seems to trigger the crash: Copying or cutting, either with keyboard shortcuts or mouse. Pasting by pushing Enter -- not right-click paste or with command-V and then copying or cutting again. But even entering some other value in between pasting by pushing Enter and then copying or cutting again will trigger the crash.
Calc also often crashes when moving cell contents to another cell.
Crashes not on first, but on second contents move.
Should also mention that it only crashes under macOS, not Linux.
Not in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 907c5d684daeb055183abb9175405c6d68fb1f49 CPU threads: 8; OS: macOS 14.3; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #8) > Not in > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 907c5d684daeb055183abb9175405c6d68fb1f49 FWIW, ATM that's more than 3 months old. In comments 0, 2, the respective builds are less than 2 weeks old ATM.
Created attachment 194857 [details] Crash log from local master build
(In reply to Patrick Luby (volunteer) from comment #10) > Created attachment 194857 [details] > Crash log from local master build I can reproduce this bug in my local master build. Crash log is in attachment #194857 [details]. I will investigate this and post when I have more news: Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 39714d3e66f92954ed08b817d56947f555054567 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
I have submitted the following fix for this bug. I will post again when the fix is available for testing: https://gerrit.libreoffice.org/c/core/+/169284
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd86e0a51a6539872f51a653580867bf0cfc22c5 tdf#161461 stop crashing by retaining NSString It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed a fix this bug. The fix should be in tomorrow's (21 June 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/796d55989cc9029d5d823ac44837583f845a3967 tdf#161461 stop crashing by retaining NSString It will be available in 24.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/4c4f8a0743765c7971f299a98946a21f28b12f9f tdf#161461 stop crashing by retaining NSString It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 161627 has been marked as a duplicate of this bug. ***
*** Bug 161587 has been marked as a duplicate of this bug. ***
*** Bug 161524 has been marked as a duplicate of this bug. ***
(In reply to Commit Notification from comment #16) > Patrick Luby committed a patch related to this issue. > It has been pushed to "libreoffice-24-8": > > https://git.libreoffice.org/core/commit/ > 4c4f8a0743765c7971f299a98946a21f28b12f9f > > tdf#161461 stop crashing by retaining NSString > > It will be available in 24.8.0.0.beta2. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. How about MacOSX-aarch64? When might a patch for this version be available?
(In reply to BROS from comment #20) > How about MacOSX-aarch64? When might a patch for this version be available? See comment #14 for how to download the 21 June 2024 or later nightly master build for either chip. I downloaded the aarch64 build just now and the fix works on my Silicon Mac.
*** Bug 161632 has been marked as a duplicate of this bug. ***
No crash. Marking Verified Fixed Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 151d997365f7bf271d63af535d29a9c3439c6d46 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Those with more in-depth knowledge, please advise a nub. After what period of time the patch is usually migrated to the final build here: https://www.libreoffice.org/download/download-libreoffice/. I tried to install the alpha on my Macbook with M1 processor and the system won't let me run it because the “file is corrupted”. If there is a way to patch by making changes to a specific file/files in the installed final build, I would be grateful for the algorithm and recommendations.
(In reply to BROS from comment #24) > Those with more in-depth knowledge, please advise a nub. After what period > of time the patch is usually migrated to the final build here: > https://www.libreoffice.org/download/download-libreoffice/. > > I tried to install the alpha on my Macbook with M1 processor and the system > won't let me run it because the “file is corrupted”. Sounds like you need to run the following Terminal command that is listed at the end of comment #14: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app If you are unfamiliar with the Terminal application, you can launch it by navigating to the /Applications/Utilities folder in the Finder and double-clicking on the Terminal application. Then, in the Terminal application window that appears, paste the above "xattr" command and press the Return/Enter key. After that, double-clicking on /Applications/LibreOfficeDev.app should launch the build that you installed. If you want to avoid all of the kludgy steps associated with the bleeding edge development builds, the LibreOffice release plan is in the following Wiki page: https://wiki.documentfoundation.org/ReleasePlan Unfortunately, the next official release (LibreOffice 24.2.5) looks like it is about a month away. But it looks like a pre-release (LibreOffice 24.8.0 RC) is scheduled for the first week of July 2024 (note: pre-releases are listed at the bottom of the main download page).
Thank you Patrick! xattr command helped.
*** Bug 161753 has been marked as a duplicate of this bug. ***
*** Bug 161493 has been marked as a duplicate of this bug. ***
*** Bug 161773 has been marked as a duplicate of this bug. ***
*** Bug 161772 has been marked as a duplicate of this bug. ***
If I may ask... With so many dupes about this crash – understandable, as copying cells is a frequent action – maybe there should be some automatic unit test (or whatever) in order to avoid re-introducing a similar problem in the future? Or maybe there is such test already, in which case please forgive my ignorance and the noise.
(In reply to ady from comment #31) > If I may ask... With so many dupes about this crash – understandable, as > copying cells is a frequent action – maybe there should be some automatic > unit test (or whatever) in order to avoid re-introducing a similar problem > in the future? Or maybe there is such test already, in which case please > forgive my ignorance and the noise. I wrote this test https://gerrit.libreoffice.org/c/core/+/169341 expecting it would crash on mac but it doesn't... I need to check with a Mac but I don't have one this week
Also tested this with a build from https://dev-builds.libreoffice.org/daily/master/current.html and I do not see the crash anymore. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c32128b35d177808df47ca98a91c2ef75e922c4a CPU threads: 16; OS: macOS 14.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Xisco Faulí from comment #32) > I wrote this test https://gerrit.libreoffice.org/c/core/+/169341 expecting > it would crash on mac but it doesn't Perhaps it depends on some setting (say, on Windows and Linux, one of those from menu Tools > Options > Calc > General > Input Settings; IDK the option path for macOS). Maybe one of the many dupes gives you a simpler/better basic test case that would include/imply this case too?
(In reply to ady from comment #34) > Perhaps it depends on some setting (say, on Windows and Linux, one of those > from menu Tools > Options > Calc > General > Input Settings; IDK the option > path for macOS). > > Maybe one of the many dupes gives you a simpler/better basic test case that > would include/imply this case too? The bug was caused by a simple coding error: assigning an autoreleased NSString that needs to survive outside of the current NSAutoreleasePool's scope. Specifically, there are two different ways to manage Objective-C objects: 1. Garbage collect them when the current NSAutoreleasePool goes out of scope. To allocate an empty NSString, you use a static call in the form [NSString string]. 2. Directly managed memory like new/delete in C++. To allocate an empty NSString, you use the form [[NSString alloc] init] and then must eventually call [myString release]. I have fixed a lot of over/underretained Objective-C bugs due to mixing up the two forms in vcl's accessibility code over the last year. This bug was just another case of that. Essentially, this is like the following C++ code. Local variable i gets deleted before returning to the caller. Maybe it won't crash because nothing has written over the deleted local variable i. NSAutoreleasePools work similarly to the C++ local variable cleanup: int* getNumber() { int i = 5; return &i; }
Created attachment 194952 [details] Patch with my failed attempt to get the crash to occur in unit test
*** Bug 161797 has been marked as a duplicate of this bug. ***
*** Bug 161802 has been marked as a duplicate of this bug. ***