Confirm with Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 9c796266470183f673eb58a8637dfe621eefa8b3
CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

With older LO, paste wasn't possible. 

No repro 7.2 so regression.
 
In 7.3 started crash on 1st paste. 
I bibisected this but not sure b/c of error: 
commit eb07a0e76fe240a184348d96a6cebf7c0a229ac0
author	Kohei Yoshida <kohei@libreoffice.org>	Mon Nov 01 2021 
Upgrade mdds and liborcus to 2.0.0 and 0.17.0, respectively.

(Somehow, I got this error: 
The following untracked working tree files would be overwritten by checkout:
	instdir/program/liborcus-0.17.so.0
	instdir/program/liborcus-parser-0.17.so.0
But it makes no sense, as these files should be in 7.3 repo. 
git clean just deleted them. 
And git fetch --all doesn't pull them again.
Xisco, please help here if you can.)

In 7.4 it became as reported. 
I tried to bibisect but it wasn't consistent, crash depends on a profile state.
Anyway, I got:
commit dddee125cc32f1ad5228e598a7de04e9654e65c1	[log]
author	Luboš Luňák <l.lunak@collabora.com>	Thu Mar 10 2022
load ods/xlsx with full row attributes without allocating all columns

(In 7.4 I have another git issue. Every while I got a message about local changes in instdir/program/python-core-3.8.12/lib/ so I'll ignore).

At the risk of adding to the confusion, here's the results of my tests.

Tried to reproduce with a debug build, but couldn't make it crash.

In the console, on opening the file, I get:

warn:sc:67217:67217:sc/source/filter/excel/xlroot.cxx:160: XclRootData::XclRootData - cannot get output device info com.sun.star.uno.RuntimeException message: "invalid attempt to assign an empty interface of type com.sun.star.frame.XFrame! at /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_master/include/com/sun/star/uno/Reference.hxx:105"
warn:sc:67217:67217:sc/source/filter/excel/xistream.cxx:762: read less bytes than requested
[...]
warn:vcl.schedule:67217:67217:vcl/source/app/scheduler.cxx:613: Stop the task before changing the priority, as it will just change after the task was scheduled with the old prio!
warn:legacy.tools:67217:67217:svx/source/form/fmvwimp.cxx:437: FmXFormView::~FmXFormView: Window list not empty!

On undoing, I get a few:

warn:legacy.osl:32591:32591:sc/source/core/data/validat.cxx:1034: ScValidationDataList: Entry not found

And on pasting the second time, I get an extra:

warn:svl.items:32591:32591:svl/source/items/itempool.cxx:442: old secondary pool: EditEngineItemPool of pool: XOutdevItemPool must be empty.

...but it does not crash.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5cd3a8ec6d36a389eb0be4d59f4570e3bda92dc5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

However, I can reproduce in a non-debug build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e125e6623fa1c0f39d927bb37547ca6d1e299cb1
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

On the bibisect repo linux-64-7.4, I used the --safe-mode flag to make sure the crash would happen. Oldest crashes on first paste, master crashes as described on second paste.
The commit where it goes from crashing on first paste to crashing on second paste is 7d314f08f10b88e356f5dbb62307d8e7f29ba922, which points to this one:

gerrit.libreoffice.org / core / db6c5c7f9dddd81a8f18a74d6051555680837adc
commit db6c5c7f9dddd81a8f18a74d6051555680837adc
author	Pranam Lashkari <lpranam@collabora.com>	Tue Apr 26 22:12:48 2022 +0530
committer	Pranam Lashkari <lpranam@collabora.com>	Mon May 09 10:05:42 2022 +0200
tree a687face663d8cdf173d4be0b7db307485135dd9
parent 920a083f3818765528899ab38170db5a2917a06c
svx: calculate object range before using it
Change-Id: I01f0176542e9d6f36a2f7bbc870a9e337705a5a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133454

(Commit also mentioned in bug 150897.)

Pranam, any idea what might be going on?

A very similar issue with Calc in 7.4.6.2 (Windows 64-bit) release: Copy/deleting contents from one cell and then pasting into another cell will frequently cause LibreOffice to freeze, necessitating a program close and restart. Usually I'm seeing this when appending to existing content in the target cell, but I've also experienced it when pasting into a blank cell 

Geoffrey Skinner <skinnerbird@gmail.com>

With original steps, no crash in:

Version: 7.5.3.1 (X86_64) / LibreOffice Community
Build ID: d29ee673721b12c92b3de9b9663473211414f0db
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Nor in recent master build.

Fix bibisected with linux-64-7.6 repo to first _good_ commit 726f156d45c6281d7034fd7d781a8a505012382d which points to:

commit e83c243018c1c7f6662f9a8ecdc731c5c071ea31
author	Kohei Yoshida <kohei@libreoffice.org>	Tue Feb 21 22:16:30 2023 -0500
committer	Kohei Yoshida <kohei@libreoffice.org>	Tue Feb 28 03:46:24 2023 +0000
tdf#153669: Track formulas that stopped listening ...
... then have them start listening again after the copy from
clipboard is complete.  Note that in case the pasted cells
are formula cells, those will be handled together as well.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147940

Marking as fixed but please can others check because I have seen some inconsistency in reproducing.

(In reply to Geoffrey Skinner from comment #4)
> A very similar issue with Calc in 7.4.6.2 (Windows 64-bit) release:
> Copy/deleting contents from one cell and then pasting into another cell will
> frequently cause LibreOffice to freeze, necessitating a program close and
> restart. Usually I'm seeing this when appending to existing content in the
> target cell, but I've also experienced it when pasting into a blank cell 

Can you please report a new bug with precise steps, and link to this one?
Thank you!