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

(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

(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. ***

*** Bug 161822 has been marked as a duplicate of this bug. ***

*** Bug 161723 has been marked as a duplicate of this bug. ***

*** Bug 161874 has been marked as a duplicate of this bug. ***

Update: the fix for this bug is now available for Mac App Store version of LibreOffice:

https://apps.apple.com/app/libreoffice/id1630474372

If you bought LibreOffice in the Mac App Store, you can get the fix by opening the App Store application on your Mac and selecting the Store > Updates menu item.

Unfortunately, the fix is not yet available in an official release from the LibreOffice website. But a new LibreOffice version is expected to be released sometime later this month (July 2024). I will post an update when the LibreOffice website has the new version.

*** Bug 161881 has been marked as a duplicate of this bug. ***

(In reply to Patrick Luby (volunteer) from comment #42)
> Update: the fix for this bug is now available for Mac App Store version of
> LibreOffice:
> 
> https://apps.apple.com/app/libreoffice/id1630474372
> 
> If you bought LibreOffice in the Mac App Store, you can get the fix by
> opening the App Store application on your Mac and selecting the Store >
> Updates menu item.
> 
> Unfortunately, the fix is not yet available in an official release from the
> LibreOffice website. But a new LibreOffice version is expected to be
> released sometime later this month (July 2024). I will post an update when
> the LibreOffice website has the new version.

Oh great. I never even knew that there was a paid version available. I've now bought it to get the update, support The Document Foundation, and to not have to worry about installing updates manually ever again.

(In reply to Patrick Luby (volunteer) from comment #42)
> Unfortunately, the fix is not yet available in an official release from the
> LibreOffice website.
24.2.5.1 (a pre-release that contains the fix) was just made available on the TDF website: https://www.libreoffice.org/download/download-libreoffice/?type=mac-x86_64&version=24.2.5

(In reply to Colin 't Hart from comment #44)
> I've
> now bought it to get the update, support The Document Foundation, and to not
> have to worry about installing updates manually ever again.
Thank you! :)

*** Bug 161882 has been marked as a duplicate of this bug. ***

(In reply to Stéphane Guillou (stragu) from comment #45)
> 24.2.5.1 (a pre-release that contains the fix) was just made available on
> the TDF website:
> https://www.libreoffice.org/download/download-libreoffice/?type=mac-
> x86_64&version=24.2.5

There is also a Mac Silicon download available via the following link so here are the links for each type of Mac:

Mac Silicon:
https://www.libreoffice.org/download/download-libreoffice/?type=mac-aarch64&version=24.2.5

Mac Intel:
https://www.libreoffice.org/download/download-libreoffice/?type=mac-x86_64&version=24.2.5

*** Bug 161888 has been marked as a duplicate of this bug. ***

*** Bug 161895 has been marked as a duplicate of this bug. ***

I have tried this fix from source, and I can confirm this to work.

But I also did an attempt to fix it, and got it 'fixed' by exiting the for loop in DataFlavorMapper::openOfficeToSystemFlavor function, when sysFlavor is been set:

for( size_t i = 0; i < SIZE_FLAVOR_MAP; ++I )
{
  if (oOOFlavor.MimeType.startsWith(OUString::createFromAscii(flavorMap[i].OOoFlavor)))
  {
    // ....

    if (bIsSystemClipboard && !strcmp(FLAVOR_LINK, flavorMap[i].OOoFlavor))
      return nullptr;

    if (flavorMap[i].SystemFlavor != nil)
      sysFlavor = flavorMap[i].SystemFlavor;
    else
      sysFlavor = OUStringToNSString(oOOFlavor.MimeType);

    // Flavor set, then break
    if (sysFlavor != nullptr)
      break;
  }
}

This was actually my first attempt to find (and hopefully) fix a bug, so my knowledge is quite limited. Wouldn't this addition speed up the function?

(In reply to Peter Hagen from comment #50)
> I have tried this fix from source, and I can confirm this to work.
> 
> But I also did an attempt to fix it, and got it 'fixed' by exiting the for
> loop in DataFlavorMapper::openOfficeToSystemFlavor function, when sysFlavor
> is been set:
> 
> for( size_t i = 0; i < SIZE_FLAVOR_MAP; ++I )
> {
>   if
> (oOOFlavor.MimeType.startsWith(OUString::createFromAscii(flavorMap[i].
> OOoFlavor)))
>   {
>     // ....
> 
>     if (bIsSystemClipboard && !strcmp(FLAVOR_LINK, flavorMap[i].OOoFlavor))
>       return nullptr;
> 
>     if (flavorMap[i].SystemFlavor != nil)
>       sysFlavor = flavorMap[i].SystemFlavor;
>     else
>       sysFlavor = OUStringToNSString(oOOFlavor.MimeType);
> 
>     // Flavor set, then break
>     if (sysFlavor != nullptr)
>       break;
>   }
> }
> 
> This was actually my first attempt to find (and hopefully) fix a bug, so my
> knowledge is quite limited. Wouldn't this addition speed up the function?

So, patrick's fix was not working for you?

*** Bug 161896 has been marked as a duplicate of this bug. ***

(In reply to Peter Hagen from comment #50)
> This was actually my first attempt to find (and hopefully) fix a bug, so my
> knowledge is quite limited. Wouldn't this addition speed up the function?

I still think the line that I changed (just after your fix) that retains sysFlavor is still necessary, but your proposed change is a good performance improvement since continuing to check every data flavor after we have already found a match appears to be unnecessary.

At the end of this comment is the patch that I copied from your change in comment #50. I can submit the patch but would you like to be credited as the author?

If yes, can you e-mail the standard License Statement to the developer e-mail list using the steps in the following Wiki page?:

https://wiki.documentfoundation.org/Development/GetInvolved/en#License_statement

I can then submit the following patch with you as author sometime this weekend:

% git diff vcl
diff --git a/vcl/osx/DataFlavorMapping.cxx b/vcl/osx/DataFlavorMapping.cxx
index 16a2c8be9207..48f261a8a065 100644
--- a/vcl/osx/DataFlavorMapping.cxx
+++ b/vcl/osx/DataFlavorMapping.cxx
@@ -577,6 +577,10 @@ const NSString* DataFlavorMapper::openOfficeToSystemFlavor( const DataFlavor& oO
                 sysFlavor = flavorMap[i].SystemFlavor;
             else
                 sysFlavor = OUStringToNSString(oOOFlavor.MimeType);
+
+            // Flavor set, then break
+            if (sysFlavor != nullptr)
+              break;
         }
     }

> So, patrick's fix was not working for you?

I was! But I made this fix before someone pointed out there already was a fix.

> I still think the line that I changed (just after your fix) that retains sysFlavor is still necessary...

I didn't mean to suggest to drop yours, I'm sure it's the best solution for this! Mine was just for an additional update.

> If yes, can you e-mail the standard License Statement to the developer e-mail list using the steps in the following Wiki page?:

Not that I care much about being mentioned, but I just send the license statement.

> I can then submit the following patch...

That would be great! I'm looking forward to help find more issues and improve the overal stability.

Peter Hagen committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e4cbe169bd1236698a573bf4758d8ae8519a1c08

Related tdf#161461: break out of loop once data flavor is set

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.

(In reply to Peter Hagen from comment #54)
> > I can then submit the following patch...
> 
> That would be great! I'm looking forward to help find more issues and
> improve the overal stability.

I have committed your change in the master branch in the following patch:

https://gerrit.libreoffice.org/c/core/+/170055

I have also submitted the same change for the upcoming LibreOffice 24.2.5 and LibreOffice 24.8 releases so you may see e-mails if those get included in those releases.

Lastly, I realized that the iOS copy and paste code which Collabora uses for their free Collabora Office for iOS product uses nearly identical code as macOS so I have submitted your change for iOS as well.

Peter Hagen committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1d4cecf2f37cd0de9e8e4bcf0c163799e9bca3f3

Related tdf#161461: break out of loop once data flavor is set

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.

Peter Hagen committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/9e30751ef80686e74e612aec4f881fe6c08eefd7

Related tdf#161461: break out of loop once data flavor is set

It will be available in 24.2.6.

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.

Peter Hagen committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/8c660b1a394f4f512a08f79e9d9fb73942f83461

Related tdf#161461: break out of loop once data flavor is set

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.

Peter Hagen committed a patch related to this issue.
It has been pushed to "libreoffice-24-2-5":

https://git.libreoffice.org/core/commit/f82ada78a3cc6cec56fd0ae4f78e33cc529e89a8

Related tdf#161461: break out of loop once data flavor is set

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.

*** Bug 161980 has been marked as a duplicate of this bug. ***

*** Bug 162000 has been marked as a duplicate of this bug. ***

Hello all,
LibreOffice 24.2.5.2 has been announced a few minutes ago containing the fix for this issue. Please download it from  https://blog.documentfoundation.org/blog/2024/07/11/libreoffice-24-2-5/

*** Bug 162142 has been marked as a duplicate of this bug. ***

*** Bug 162232 has been marked as a duplicate of this bug. ***