I can confirm this. 

I did this with Linux/Debian10 and LibreOffice versions 6.1 , 6.3 and 7.0 . 

Versions 6.3 and 7.0 both crashed, but not at the same point. They also crashed at a different point when Telesto did this.

To make sure that regular users don't loose confidence in LibreOffice, I appreciate it if crashes can be handled with more importance. The "importance" is now "medium/normal" and I didn't change it. For now I'd like to leave it up to others if this needs to be changed.

Gosh, for a change I'm not adding any attachments. :-D

   Here are a few details:

LibreOffice 6.1 :
1. Open attachment 155421 [details] 
2. Toggle formatting marks on
3. CTRL+A (3x)
4. CTRL+X
5. CTRL+Z
6. CTRL+X
7. CTRL+Z
8. CTRL+X 
   (There's now one formatting mark)
9. Click the top one
   (That works fine.)


LibreOffice 6.3 :
1. Open attachment 155421 [details] 
2. Toggle formatting marks on
3. CTRL+A (3x)
4. CTRL+X
5. CTRL+Z
6. CTRL+X
7. CTRL+Z
   (This is where LibreOffice 6.3 crashes)


LibreOffice 7.0 :
1. Open attachment 155421 [details]
2. Toggle formatting marks on
3. CTRL+A (3x)
4. CTRL+X
5. CTRL+Z
6. CTRL+X
7. CTRL+Z
8. CTRL+X
   (This is where LibreOffice 7.0 crashes. It crashes before
    I can see if there are one or two formatting marks.)

					~~~

   Here are the versions that I used:

Version: 6.1.5.2
Build ID: 1:6.1.5-3+deb10u5
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

Version: 6.3.4.1
Build ID: a21169d87339dfa44546f33d6d159e89881e9d92
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Version: 7.0.0.0.alpha0+
Build ID: 4d03bd252274308f64332e7c0523068c38ac684a
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-04-26_05:59:56
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

> To make sure that regular users don't loose confidence in LibreOffice, I
> appreciate it if crashes can be handled with more importance. The
> "importance" is now "medium/normal" and I didn't change it. For now I'd like
> to leave it up to others if this needs to be changed.


https://crashreport.libreoffice.org/stats/crash_details/298aa625-ba01-4f82-9bca-d5dbd1840eeb

LibreOffice 6.1 not doing well either; no crash, but empty dialogs/ not responding
Also bit reluctant increasing priority. I can't tell how often it in reality crashes... 

You're/ Im allowed to set it too high, critical based on the flow chart https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg

A downgrade is always possible', so lets try it for the difference.

Note 1: there are quite a number of crash bugs with 'medium/normal'; some corner cases and some which should have more urgency, IMHO
Note 2: I'm the bugtracker spam bot (once in a while); filling the bug tracker with more (unconfirmed) bugs.

No repro. Maybe re-test as there were many related fixes lately.

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8fe03ea93213bbb19b6ee9862a3966144f0df5cb
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded

No repro
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 4c14c88cc681abab787a461a1bea502a777f37e6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

There is still another crash in here.. but related to redo

Fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=55576842ec72a748d0bad123d41fa03c89fc136d
Closing as dupe of bug 131684

*** This bug has been marked as a duplicate of bug 131684 ***